mobilecoinfoundation / attestation Goto Github PK

The quoting enclave ID needs to be verified.
The access point for the id and what to check is documented here, https://api.portal.trustedservices.intel.com/documentation#pcs-enclave-identity-v4

Determining if the identity of a SGX Enclave (represented by SGX Enclave Report) matches a valid, up-to-date Enclave Identity issued by Intel requires following steps:

1. Retrieve Enclave Identity(SGX QE, TDX QE or QVE) from PCS and verify that it is a valid structure issued by Intel.
2. Perform the following comparison of SGX Enclave Report against the retrieved Enclave Identity:
   a. Verify if MRSIGNER field retrieved from SGX Enclave Report is equal to the value of mrsigner field in Enclave Identity.
   b. Verify if ISVPRODID field retrieved from SGX Enclave Report is equal to the value of isvprodid field in Enclave Identity.
   c. Apply miscselectMask (binary mask) from Enclave Identity to MISCSELECT field retrieved from SGX Enclave Report. Verify if the outcome (miscselectMask & MISCSELECT) is equal to the value of miscselect field in Enclave Identity.
   d. Apply attributesMask (binary mask) from Enclave Identity to ATTRIBUTES field retrieved from SGX Enclave Report. Verify if the outcome (attributesMask & ATTRIBUTES) is equal to the value of attributes field in Enclave Identity.
3. If any of the checks above fail, the identity of the enclave does not match Enclave Identity published by Intel.
4. Determine a TCB status of the Enclave:
   a. Retrieve a collection of TCB Levels (sorted by ISVSVNs) from tcbLevels field in Enclave Identity structure.
   b. Go over the list of TCB Levels (descending order) and find the one that has ISVSVN that is lower or equal to the ISVSVN value from SGX Enclave Report.
   c. If a TCB level is found, read its status from tcbStatus field, otherwise your TCB Level is not supported.

SGX SDK/DCAP implementation is here https://github.com/intel/SGXDataCenterAttestationPrimitives/blob/DCAP_1.16/QuoteVerification/QVL/Src/AttestationLibrary/src/QuoteVerification.cpp#L260

• #104
• #105
• #106

Need a verifier for the Quoting Enclave report body. This is steps 2-4 from
https://api.portal.trustedservices.intel.com/documentation#pcs-enclave-identity-v4

Determining if the identity of a SGX Enclave (represented by SGX Enclave Report) matches a valid, up-to-date Enclave Identity issued by Intel requires following steps:

1. Retrieve Enclave Identity(SGX QE, TDX QE or QVE) from PCS and verify that it is a valid structure issued by Intel.
2. Perform the following comparison of SGX Enclave Report against the retrieved Enclave Identity:
   a. Verify if MRSIGNER field retrieved from SGX Enclave Report is equal to the value of mrsigner field in Enclave Identity.
   b. Verify if ISVPRODID field retrieved from SGX Enclave Report is equal to the value of isvprodid field in Enclave Identity.
   c. Apply miscselectMask (binary mask) from Enclave Identity to MISCSELECT field retrieved from SGX Enclave Report. Verify if the outcome (miscselectMask & MISCSELECT) is equal to the value of miscselect field in Enclave Identity.
   d. Apply attributesMask (binary mask) from Enclave Identity to ATTRIBUTES field retrieved from SGX Enclave Report. Verify if the outcome (attributesMask & ATTRIBUTES) is equal to the value of attributes field in Enclave Identity.
3. If any of the checks above fail, the identity of the enclave does not match Enclave Identity published by Intel.
4. Determine a TCB status of the Enclave:
   a. Retrieve a collection of TCB Levels (sorted by ISVSVNs) from tcbLevels field in Enclave Identity structure.
   b. Go over the list of TCB Levels (descending order) and find the one that has ISVSVN that is lower or equal to the ISVSVN value from SGX Enclave Report.
   c. If a TCB level is found, read its status from tcbStatus field, otherwise your TCB Level is not supported.

One possibility is similar to the MrSignerVerifier implementation.
We could create a newtype struct QeReportBody(ReportBody) and derive a verifier for this newtype, composed of AndVerifiers, or perhaps manually anded, for all of the fields that need to be verified.

• #49
• #70
  • #71
• #51
• What do we do about alloc? Updated #49 to use an alloc feature
• #68
• Build a valid certificate chain from a collection of certificates, https://www.rfc-editor.org/rfc/rfc4158
• #79
• Need to define/determine how much of https://www.rfc-editor.org/rfc/rfc5280 we're going to support
• ignore bidi code points as specified in https://www.rfc-editor.org/rfc/rfc4518#section-2.5
• fail on prohibit code points as specified in https://www.rfc-editor.org/rfc/rfc4518#section-2.5 (Note that these points specified are from unicode 3.2)

• #3
• #9
• #10
• #11
• #18
• #20
• #21
• #22
• #34
  • mobilecoinfoundation/sgx#286
  • mobilecoinfoundation/sgx#285
  • mobilecoinfoundation/sgx#283
• #42
• #38
• #39
• #40
• #41
• #30

from, #25 (review)

Right now in EPID land, report_data contains two things: 32 bytes of static noise identity public key, and 32 bytes of app-specific data we want to attest to (e.g. in consensus, this is a block signing public key, in fog ingest this, is the ingress public key---i.e. the key that senders should encrypt their fog hint for). When we switch to DCAP, I'd like to change this to some kind of a MAC over an associated data structure that contains these keys (i.e. give us more than 64 bytes worth of data that we can attest to), but that's not how it works now.

The upshot is that right now, mc-attest-ake needs to be able to check that the first 32 bytes match, and ignore the rest of ReportData.

To reiterate it's that currently EPID verification does [EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX], where E is expected value and X is don't care.

The advisories are provided in json format via https://api.portal.trustedservices.intel.com/documentation#pcs-tcb-info-v4

for example

curl "https://api.trustedservices.intel.com/sgx/certification/v4/tcb?fmspc=00906ED50000"

The TCB format is specified in https://api.portal.trustedservices.intel.com/documentation#pcs-tcb-info-model-v3

The signature is over the tcbinfo contents so need to strip off the {tcbinfo: from the string.

We will want a JSON parser that doesn't walk down past the initial tcbInfo when looking for the signature.

Think the signing key comes from the request can see the chain with curl -v

TCB Test cases

• duplicate tcbInfo fields. Simulates a malicious actor appending another tcbInfo field to the json hoping the first tcbInfo get's verified

  {
    tcbInfo: {},
    signature: "",
    tcbInfo: {}
  }
       

• tcbInfo doesn't contain valid json. Ensures the parser that is looking for the root signature field errors properly and verification does not happen
• tcbInfo contains a signature field. Ensures that the root signature is used by the verification logic. Simulates a malicious actor nesting signed tcbInfo inside of the root tcbInfo

PRs

• #83
• #84
• #85

• #2

• #50 being dropped in favor of #91
• #97
  • mobilecoinfoundation/sgx#332
  • #96
• #64
• #65
• #91
• #98

• mobilecoinfoundation/mobilecoin#3127
• Decide whether we want CT or not. Long term we do for now we're ok with non constant time
• #8
• #6
• #7
• #15
• #46
• #101
• #126
• Implement example of usage to ensure the API meets the needs This was done as an exercise, but was not committed as the main MobileCoin repo will be able to stand in as the example.

Currently there are multiple todo's to convert the verification with eq to constant time.

• Integrate with mobilecoinfoundation/sgx#280
• Update EqualityVerifier to use ct_eq()
• Make generic Verifier for GreaterThanEqualVerifier

In #2 we settled on an error tree that contains all the errors about verifying data.
We want some way to display this in an ergonomic way so that humans can more easily fix verification issues.
One thought is out put like

Report Error:
  and: 
    Attributes failed (expected, actual)
    and:
      SVN (passed)
      product ID (passed)

The above is a very rough draft, the idea being that the error tree can be visually represented and humans can quickly find the failures.
it may be that only failures are shown.

• mobilecoinfoundation/sgx#319
• #31
• #48 This includes
  • Not display
  • Mrsigner display
• Need accessor methods for Attributes, in #48 going to the wrapped C struct and accessing the fields directly This is now handled by the Display trait on Attributes
• #86
• #87

Need to provide the ability to verify certificate chains, both for the TCB certs and the PCK cert chain contained in the quote bytes, https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_SGX_ECDSA_QuoteLibReference_DCAP_API.pdf#%5B%7B%22num%22%3A75%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C69%2C687%2C0%5D
This ability needs to be specified per client, but an implementation that works inside of an enclave needs to be provided.

• #92
• #93
• #94
• #95

Given a set of allowed advisories, ensure only the allowed advisories are present in the TCB info

• #90

Use the PKI test suite, https://csrc.nist.gov/projects/pki-testing, to verify the certificate chain logic

• #73
• #75
• #76
• #78

In order to make the verifier more ergonomic and consistent we should provide a verifier that looks at the overall evidence (quote and collateral) to verify.

• #124
• #125
• Add consolidated verifier
  • #127
  • #128
  • #129
  • #131
  • #132
  • #135