This article is licensed under CC BY-NC-SA 4.0

This article brings up the topic that the SGX Enclave, especially the DCAP Quoting Enclave¹, can have too many “identities”. This can be more or less an obstacle in the way towards formal verification.

This was partly my student research project in the uni.

Contents

• Confidential Computing and Attestation: an overview.
• Intel SGX and DCAP: a quick introduction, also a recap of what I’ve learned.
• Discussion of Enclave Identity, especially Quoting Enclave Identity.

Quick reference for Background Knowledge

• Intel SGX²
• Intel DCAP¹

DISCLAIMER:

• Please understand that this article is just my notes on what I’ve learned and what I understand.
• This is not a tutorial, it hope it helps you but don’t just trust my words.
• Copying: please keep attributions AS-IS. See CC BY-NC-SA 4.0.

I’m open to discussion via email.

Motivation

One thing I find confusing during my student project is that, the term “identity” is not precisely defined and different “forms” of identities are used in different contexts for different purposes. Each “identity” can have different dependencies(as in how the token is derived) and format(a semantic string? a hash? a structured data like json?). In early phase of my study, I was using “duality of QE identity”. As I proceed, I realize it’s more than “duality”, it’s schizophrenia.

Schizophrenia in software engineering³ happens in Object Oriented Programming, where this/self of a class (or its object) could refer to multiple objects. I use the same metaphor here because it precisely describes the concern.

CC and Attestation - a quick overview

If you care about this topic I suppose you already know the basics, but I’ll write a basic introduction here to put everyone on the same page.. Skip this section in case you want to go directly to the point.

Confidential computing(CC) or TEE⁴ deals with the attacker model that the platform owner, who hosts your applications, and has high privileges, can be hostile. For example, the hypervisor can read your VM’s memory. In other words, CC protects Data in use, in contrast to data in storage that can be protected via encryption and data in transport that can be protected by TLS.

To support CC, processor vendors provides HW solutions such as Intel’s SGX (and TDX), AMD’s SEV and Arm’s CCA. This article will not go into details of these.

These mechanisms provides an environment where your code and data are protected from another party who has even higher privileges on the platform, such as a hypervisor. The HW makes sure that, for example, some memory regions can only be accessed by your program, even when it’s running on the lowest privilege level. As a starting point of this article, let’s ignore the implementation details and just assume that there is a magic “execution space” on the platform that is assigned exclusively to your program, and you can safely handle your secret data there, if

1. your program is correctly loaded into that “space”
2. the hardware is real(i.e. not emulated) and genuine(i.e. produced by a trusted vendor such as Intel), and the firmware is to be trusted(e.g. has no known security exploit)
3. (optionally) the platform itself is setup correctly, as claimed by the platform provider.

Intel SGX

acknowledgement: My knowledge on the SGX technical details, is heavily taught by the Intel SGX Explained² article. Much of what I write here is what I take away, and I won’t repeatedly refer to that article in this section.

The “magic place” in Intel SGX is called “Enclave”. I’m only covering some key concepts of SGX. And I won’t talk about TDX at all.

Intel SGX is a process based TEE(in contrast to TDX, a VM based TEE). The user program is divided into a “safe” part(i.e. enclave) and an “unsafe” part. A region in the physical memory (Processor Reserved Memory, PRM) is protected from non-enclave access. The PRM contains the following essential parts:

• Enclave Page Cache (EPC). EPC holds 4k pages that are mapped into user process’s virtual address space for enclave code and data.
• EPC Metadata (EPCM) for each page in EPC, there exists an EPCM Entry that tracks the EPC Page’s state, e.g. the owner enclave,
• SGX Enclave Control Structure (SECS). SECS stores metadata per loaded enclave. Each SECS is stored in a dedicated EPC page and can only be accessed by CPU’s SGX implementation. (i.e. privileged and not mapped to any virtual page)

I won’t go through the detailed life cycle of an Enclave. I’ll briefly cover the initialization of an Enclave and its Measurements.

As mentioned above, there is a continuous chunk in the Process’s virtual memory space, that is mapped into EPC Pages. The EPC Pages lives in a continuous and privileged region in the main memory. To initialize an Enclave, the process asks HW to initialize EPC Pages and load Enclave code and data into them. During this phase, a SHA256 measurement called MRENCLAVE will be calculated.

MRENCLAVE and Enclave initialization
When all EPC Pages are created and initialized ⁵, an EINITTOKEN will be emitted which indicates that the enclave is fully loaded, EPC pages can no longer be added after this point and the MRENCLAVE is set to a final value. Note that the MRENCLAVE represents the Initial State, including the code and data, of an Enclave. In other words, if the platform can provide a trusted(i.e. not forged) value of Enclave’s MRENCLAVE that matches your expectation, you know that the enclave initialized into the correct state.

MRSIGNER
The MRENCLAVE represents the Enclave’s initial state, but sometimes the MRENCLAVE means little to you, especially when you are using a third-party Enclave. For example, like in later text we cover remote attestation that requires architectural enclaves. For these enclaves, certainly you can attest them by checking their MRENCLAVE, but how do you know if this MRENCLAVE is correct? In this case you want a certificate of this Enclave, that is signed by the Enclave vendor, like Intel. Another measurement namely MRSIGNER is for this purpose.

                 Header
                +------------------+
                | Meta data of     | 
                | Sienger and the  |--------+
                | Certificate      |        |
                +------------------+        |
                                            |
                +------------------+        |
    ------------| SIGSTRUCT Header |--------+
    |           +------------------+                  +----------+
    |           | ISV PUBKEY       |------SHA256----> | MRSIGNER |
    |           +------------------+                  +----------+
    +---ISK*--->| ISV SIGNATURE    |
    |           +------------------+
    ------------| SIGSTRUCT Body   |--------+
                +------------------+        |
                | ISV PUBKEY       |        |
                +------------------+        |
                | Q1 / Q2 *        |        |
                +------------------+        |
                                            |
                  Body                      |
                +------------------+        |
                | Enalve attrib.   |        |
                | ISV PRODID       |--------+
                | ISVSVN           |
                | MRENCLAVE        |
                | ......           |
                +------------------+


* Header and Body are signed by ISV Signing Key (RSA-3072)
* MRSIGNER is created from ISK's public key
* Q1 and Q2 are calculated during signing, they are used to
  verify the signature.

fig 0. SIGSTRUCT and MRSIGNER

As shown in the above figure, SIGSTRUCT is a certificate of the Enclave, signed by its vendor. When the enclave is created, the SGX implementation will make sure that the actual parameters of the Enclave matches the Vendor’s specs. Now you can verify the enclave’s “certificate” from its vendor rather than the raw MRSIGNER.

Key Fuses
A Core part of the whole attestation⁶ is the Key Fuses. This is the starting point of your chain of trust and the root of all SGX keys. The Key Fuses are Hard-wired secrets, which are implanted into the processor during manufacturing in the Intel factory. These fuses can only be accessed by the Processor with certain SGX instructions. In fact, SGX does not directly use these secrets as, for example, keys. Instead, SGX uses Keys(see below) that are derived from these fuses (EGETKEY instruction).

On the other hand, these keys are KNOWN TO Intel, so that the platform can somehow prove to Intel that it is genuine Intel Hardware, and so that with the help of Intel services the relaying parties can attest the platform.

SGX Key.
A SGX Key is provided by SGX Hardware to the Enclaves for various cryptographic purposes. Each key is derived from HW Key fuses and various fields related to the key owner Enclave. We can assume that each Enclave is guaranteed to get its unique (even for the same key type) keys with exclusive access.

There are different SGX Key types for example:

• Report Key: used to create a CMAC block for an SGX report, used in local attestation (see below).
• Seal Key: can be used to encrypt data, or used as seeds for other purposes.
• Provisioning Key: related to provision of AK. We’ll see this later.
• …

SGX Report
A SGX Report is created for an enclave, containing the Enclave’s measurements among other parameters. Notably the SGX Report can be optionally targeted at another enclave. In this case, the report’s body will be CMAC’ed with another Enclave’s Report Key, and this report can be exclusively verified by the targeted Enclave (because only that enclave can access the Report Key).

Local Attestation - For an Enclave to trust another

    +-------------------+  (Nonce)   +-------------------+    
    |    Enclave A      |<-Challenge-|    Enclave B      |    
    |                   |            |                   |    
    |                   |--Report--->|                   |    
    +-------------------+            +-------------------+
           |   ^                             |   ^        
    Target.B   |Report               Key Req.|   |Report Key
           v   |                             v   |         
    +----------------------------------------------------+    
    |              SGX HW and implementation             |   
    +----------------------------------------------------+    

    * In reality an Enclave DOES NOT directly call[^call] another
      Enclave.
    fig 1. SGX Local Attestation

As shown in figure 1, the SGX report is used to establish trust between enclaves on the same platform (i.e. local attestation). A simplified process can be summarized as follow:

1. (Host process of) Enclave B sends challenge to (Host process of) Enclave A.
2. Enclave requests a report from HW, targeting enclave B. This report will contain Enclave A’s information including its measurements and parameters, and the report is CMAC’ed with Enclave B’s report key. Note that the report’s body can also contain a Nonce from B’s challenge (namely report data field), thus guarantee the freshness of the report and prevent replay attacks.
3. The HW Creates the required report for A, which is then sent back to Enclave B.
4. Enclave B acquires its Report Key from HW and use it to verify the CMAC signature of the report.
5. If the report is verified, B will know that A is on the same platform and is a genuine SGX Enclave with the expected parameters.
6. Process 1-5 can be done vice versa for Enclave A to trust Enclave B. Then they can establish a secured channel based on the attestation process.

Remote Attestation

At the end of the day, you as the relaying party, want to provision secrets(say, medical data of a patient) to the program that processes that data, which runs in the magic safe space. But how do you attest the three⁷ prerequisites(as in claimed by the platform provider) above? And how do you do that when you are NOT on the same platform as the TEE? This is where remote attestation comes in.

The verifier⁸ knows that the platform(more precisely, the TEE it provides) can be trusted, because the following are attested.

• The User Enclave⁹ i.e. the TEE where the user puts sensitive data and runs trusted operations.
• The Architectural Enclaves that are involved in attesting the User Enclave
• The CPU Firmware, identified by the CPU (Security Version Number) SVN.
• The hardware

Fundamentally, there are two things you want to make sure of(attest)

• The correct initial state of your Enclave
• The genuine TEE (incl. HW, Firmware, Architectural Code etc.)

The following diagram shows Intel’s SGX EPID based remote attestation.

        +------------------------------------------------+    
        |            Platform (SW)                       |    
        |                                                |         
        | +---------------+        (EPID based)          |         +-------------+
        | |               |--------Proof of genuinty-------------->|             |
+--------->   PvE*        |                              |         |  Intel      |
|       | |               |<-------New AK joins------------------->|             |
|       | +---------------+        EPID Group            |         +-------------+
|       |    |                                           |              |
|       |    |AK Provisioning*                           |              | Verify AK
|       |    |                                           |              | 
HW      | +---------------+ 2.Local    +---------------+ |         +-------------+
Secret  | |   Quoting     |<--Att.---->|  App. Enclave |<--1.Ch*---|             |
|       | |   Enclave     |            |               | |         |  Verifier   |
|       | |               |---Quote--->|               |---Quote-->|             |
|       | +---------------+            +---------------+ |         +-------------+
|       |    |   ^                             |   ^     |           Verify Quote
|       |    |   |                      2.     |   |     |    
|       | 3.Verify Enclave Report       Generate Report  |    
|       |   (local att.)                (Targeting QE)   |    
|       |    |   |                             |   |     |    
|       +----|---|-----------------------------|---|-----+    
|            |   |                             |   |      
|       +----v---------------------------------v---------+
+-------|          SGX HW and implementation     ____    |
        |                                       |FUSE|<-------Known to Intel
        |                                        ----    |
        +------------------------------------------------+

    * PvE: Provisioning Enclave
    * AK: Attestation Key
    * In reality the verifier DOES NOT directly interact with enclaves, 
      neither does an enclave with another enclave.The diagram ignores
      such such details for simplicity.[^call]
    * A Certified AK is stored sealed with Provisioning Seal Key
      QE can get this key from SGX HW and decrypt the AK to use.   

    fig 2. SGX Remote Attestation (EPID based)

The diagram is scary but the principle is simple:

• There is another Enclave, namely Quoting Enclave, on the platform. When you challenge your App enclave an attestation (step 1), the App will submit an Report from your the App Enclave to the Quoting Enclave, and the Quoting enclave verifies your application Enclave via Local Attestation (Step 2, also figure 1).
• The Quoting Enclave assembles a so called “Quote” data structure, which contains 1) The report from App Enclave, 2) The report for QE itself 3) Meta Data of the Quote structure and 4) Certificate related data.
• The Quote is signed with a asymmetric key (Attestation Key, AK), the signature is also a part of the Quote.
• The Quote is sent back to the Verifier, and with the help of Intel Service, you can verify Quote (i.e. Certificate). Thus gain trust in the App enclave.

I know I’m overlooking one or two gorillas in the room:

• what the heck is this AK and why should you trust its signature (i.e. the holder of AK private key)? and
• why should you trust the Quoting Enclave? and
• what the heck is this PvE?

If you are OK having some doubts, jump to the next section, otherwise I’ll try my best to explain now.

Provisioning Enclave, PvE
We’ve looked at the SGX hardware fuses. In fact there are two fuses namely the Seal Fuse and Provisioning Fuse. These two fuses are used to derive different type of keys. But we can overlook this detail for now.

The fact that a valid¹⁰ HW fuse is present in a processor fundamentally proves that the Processor is genuine Intel SGX Hardware. Now, the platform must first demonstrates to Intel that it’s in procession of the HW secrets in order to obtain a Certificate for its Quote signing Key(AK). Here Intel acts as a Certificate Authority. This is the responsibility of PvE.

In short, the PvE 1) proves to Intel the platform has SGX properly setup and 2) gets an Attestation Key that’s endorsed by Intel. The Attestation Key is stored encrypted for Quoting Enclave to use later. The process is done with Intel’s EPID scheme.

Enhanced Privacy ID (EPID)

Intel’s EPID¹¹ is to, as the name suggests, protect privacy during Certificate verification. In the de-facto asymmetric signature scheme, a certificate is signed by signer’s private key and verified by the signer’s public key. The public key is pretty much equivalent to the identity of the signer. However this is sometimes not desired. For example, you want to certified yourself as “belonging to a group”, but you don’t want to necessarily identify yourself.

The EPID scheme can be summarized as:

• Each member of the group has its own private key(that is not known to anyone else).
• Each member joins their key to the group via EPID protocol
• Each member signs with its own private key
• The signature can be verified by the group’s public key, which is shared by all the members.

Since the certificate signature is no longer identified by the signer’s public key, the signer identity is hidden.

In CC Attestation, when using “traditional” asymmetric signature, a platform is bound to (and identified by) its Quote signing key(AK). Furthermore, the Quote will be associated to a certain CPU that produces it. What actually happens in figure 2 is that:

• The PvE derives the EPID signing key from its hardware secret, and submits a signature to Intel, so that Intel knows the processor is one of their SGX products, without knowing exactly which one.
• After being verified by Intel, PvE derives a Attestaion Key, and let this Attestation Key join a EPID group. So that the AK Signature (of the Quote) can be verified by the EPID group public key, instead of the AK’s public key. Therefore the verifier knows the Quote is signed by one of the genuine SGX hardware, without knowing exactly which one.

Summary of EPID RA, the Chain of trust

Finally, let me try to put things together with this diagram of Chain of Trust¹².

Chain of Trust

       +----+      +----------+
       |FUSE|----->| Intel CA |                 -Intel Root CA Cert-
       +----+      +----------+                
        ||             |
      1 ||             |                         
        ||      +------v---------+
        |+--2---| AK Certificate |              -EPID Group pubkey-
        ||      +----------------+
        ||             |
        ||           +-v--+                     -Attestation Key-
        |+--3--------| AK |                      Only accessable to Intel QE
        ||           +----+                      and Intel PvE
        ||             |
        ||          +--v--------+
        |+--4-------| SGX Quote |               -Signed by AK-
        ||          +-----------+
        ||                  \
        ||              +----v---------------+
        |+--5-----------| App Enclave Report |  -Wrapped in Quote-
        ||              +--------------------+
        ||                    ||
        vv         6          vv
     [TEE*(SGX)] ------- [Enclave State]        
                        -Wrapped in Report-


[*] TEE: Trusted Execution Environment. Here TEE is SGX TCB with
      - genuine SGX Hardware (as in endorsed by Intel)
      - genuine Software (as in endorsed by Intel)
      - Firmware security version number >= expected
      - (Optionally) Architectural software (enclaves)
        Security Version Number >= expected

    TEE is involved in every part of the chain, as in numbered 1~6.

Let me repeat, there are two essential parts you want to attest:

• The correct initial state of your Enclave
• The genuine TEE (incl. HW, Firmware, Architectural Code etc.)

They are shown at the bottom of this diagram.

TEE is involved in many steps of the process (numbered in the diagram):

1. Only enclaves with proper privileges can access the hardware secret by requesting a SGX Key that is derived from the FUSE. PvE use this derived key (Provisioning Key) together with EPID to prove its identity to Intel.
2. The AK certificate (i.e. AK successfully joined Intel EPID Group) shows that the SGX hardware has been attested by Intel.
3. Only Intel QE and PvE can access the encrypted AK by requesting Provisioning Seal Key from SGX hardware, therefore a certified AK will not be used by a malicious party to fake a Quote.
4. The SGX Quote can only be generated and signed for a SGX Enclave (verification via local attestation).
5. SGX makes sure that each Enclave’s report can only be accessed by the owner Enclave.
6. SGX implementation keeps track of Enclave State, e.g. the measurements. The Enclave State is only visible to the owner Enclave.

Remote Attestation with Intel DCAP

Finally we can move on to DCAP[^decap]. For short, the PvE is replaced by PCE and the EPID based certificate verification is replaced by a cert chain containing PCK.

                +---------------------------+                                       
                |      PLATFORM             |        
                |   +-----------------+     |  1.Challenge   +-----------------+
                |   |  Application    |<----+----------------| Remote Verifier |
                |   |  +---------+    |     |                | / Challenger /  |
                |   |  | App     |    |     |  4.Quote       |  Relaying Party |
        +-------+---+->| Enclave |    |-----+--------------->|                 |
     S  |       |   |  +---------+    |     |                +-------^---------+
     G  |       |   |    |            |     |                        |
     X  |       |   +----+----^-------+     |                        | Cert
        |       |        |    |             |                        | Collaterals 
        |       | 2.Report   3.Quote        |                        | (e.g. CRLs)
     F  |       |        v    |             |                        |
     U  |       |   +-------------+  PCK  +--------+                 |   
     N  +-------+-->| QE (AK)     |<-Cert-|        |         +-----------------+
     C  |       |   +------^------+       | Plat.  |         |   Intel         |
     T  |       |          |              | Cert   |---Sync--|   Attestation   |
     I  |       |          | 0.setup      | Cache  |         |   Service (IAS) |
     O  |       |          |              +--------+         +-------^---------+
     N  |       |   +------v------+         |                        |
     S  +-------+-->| PCE (PCK)   |         |                        |
        |       |   +-------------+         |                        ^
        |       |                           |                        |
        |       +---------------------------+                     Known To
        |                                                            |
        |       +---------------------------+                        |
        |       | Platform HW       ____    |                        ^
        +-------|  (SGX IMPL. )    |FUSE|---+------------------------+
                |                  `----`   |
                +---------------------------+
    
    fig 3. DCAP Remote Attestation

DCAP - the Motivation

Well, this is not the “official” motivation. No one knows why X does Y, we can only guess.

As we see in the EPID attestation workflow

// PLACE HOLDER

TEE Identity

There are many forms of identities:

// PLACE HOLDER // PLACE HOLDER

The identities in DCAP

What “identities” are there in DCAP?
placeholder

What exactly are these identities? How are they derived, and what are, if any, the implicit dependencies among these identities?

Summary

Name	Usage	Dependencies	Who use it	Where Stored	Format	QE only?
EINIT Token	to specify an enclave on the Platform	counter	Platform	SECS	?	N
SECS Ptr	?	?	SGX impl (HW)	PRM	Addr	N
KEYID	specify the QE to load(init)	?	Platform	Platform config	? / c struct	Y
MRSIGNER	-	-	-	report	SHA256	N
MRENCLAVE	-	-	-	report	SHA256	N
QEID	Map PCK Cert to QE	PH	Platform fetching PCK; Cert cache server	ECDSA blob	PH	Y
QE Report	Quote verification	SGX report	Verifier	Quote	bstr	?
QE Identity	Quote verification	specified by intel placeholder	Verifier	Intel	JSON	Y
?	PCE Verifies QE	HW (Local Attestation)	PCE	QE Report	SGX Report	Y

Works

// placeholder // placeholder // placeholder

the comment system on this blog works via email. The button
below will generate a mailto: link based on this page's url 
and invoke your email client - please edit the comment there!

[optional] even better, encrypt the email with my public key

- don't modify the subject field
- specify a nickname, otherwise your comment will be shown as   
  anonymous
- your email address will not be disclosed
- you agree that the comment is to be made public.
- to take down a comment, send the request via email.