Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend SGX-support to describe other properties without relying on OE/Gramine-verify. #175

Open
gapisback opened this issue Aug 7, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@gapisback
Copy link
Collaborator

gapisback commented Aug 7, 2023

When we do verification on SGX platform, we need enhancements to return other 'collateral' (to be specified).

in SEV, we check platform properties, e.g. if debug is turned ON, if you can share keys w/ other platforms, API u-code level etc.

We don't do that for SGX. We only check is the measurement. Reason we don't check is : That was not one of the things returned by OE-verify, Gramine-verify (on SGX platform).

We don't check SGX-report directly. We rely on OE/Gramine to do some of the verification / signature(s).

We don't rely on them to check the measurements; we do that directly.

We should directly check the SGX-properties (e.g. debug, whether this enclave allows other enclaves to debug it, TCB-version etc ...) ourselves.

Dependencies: Ye has to do something first, and then John can work on this.

@gapisback gapisback added the enhancement New feature or request label Aug 7, 2023
@gapisback gapisback changed the title Extend SGX-support to describe other properties (TBD ... to be filled-out). Extend SGX-support to describe other properties without relying on OE/Gramine-verify. Aug 21, 2023
@yelvmw
Copy link
Contributor

yelvmw commented Aug 21, 2023

Open Enclave claims are extracted from evidence/endorsement as part of the verifier interfaces. The claims are returned by the verifier as an array of oe_claim_t elements:

typedef struct _oe_claim {
  char *name;
  uint8_t *value;
  size_t value_size;
} oe_claim_t;

oe_claim_t claims[] = {
  // The OE known, or standard claims required by any implementation. Though the meaning of each can be interpreted differently for different backends.
  {"id_version" : "xxxxxx"}, // Claims version.
  {"security_version" : "xxxxxx"}, // Security version of the enclave (SVN for SGX).
  {"attributes" : "xxxxxx"}, // Attributes flags for the evidence.
  {"unique_id" : "xxxxxx"}, // The unique ID for the enclave (MRENCLAVE for SGX).
  {"signer_id" : "xxxxxx"}, // The signer ID for the enclave (MRSIGNER for SGX).
  {"product_id" : "xxxxxx"}, // The product ID for the enclave (ISVPRODID for SGX).
  {"format_uuid" : "xxxxxx"}, // The format id of the evidence.

  // OE optional claims
  {"validity_from" : "xxxxxx"}, // Overall datetime from which the evidence and endorsements are valid.
  {"validity_until" : "xxxxxx"}, // Overall datetime at which the evidence and endorsements expire.

  // OE custom claim
  {"custom_claims_buffer" : "xxxxxx"}, // Custom claims in a flat buffer, for evidence generated by oe_get_evidence().

  // SGX required claims
  {"sgx_pf_gp_exit_info_enabled" : "xxxxxx"},
  {"sgx_isv_extended_product_id" : "xxxxxx"},
  {"sgx_is_mode64bit" : "xxxxxx"},
  {"sgx_has_provision_key" : "xxxxxx"},
  {"sgx_has_einittoken_key" : "xxxxxx"},
  {"sgx_uses_kss" : "xxxxxx"},
  {"sgx_config_id" : "xxxxxx"},
  {"sgx_config_svn" : "xxxxxx"},
  {"sgx_isv_family_id" : "xxxxxx"},

  // SGX optional claims
  {"sgx_tcb_info" : "xxxxxx"},
  {"sgx_tcb_issuer_chain" : "xxxxxx"},
  {"sgx_pck_crl" : "xxxxxx"},
  {"sgx_root_ca_crl" : "xxxxxx"},
  {"sgx_crl_issuer_chain" : "xxxxxx"},
  {"sgx_qe_id_info" : "xxxxxx"},
  {"sgx_qe_id_issuer_chain" : "xxxxxx"},
};

Optional claim reliability is questionable. Especially across OE SDK versions. More claims were added in later versions.

@gapisback
Copy link
Collaborator Author

Revisited the scope of this issue: As there seems to be some ambiguity w.r.t how-to get all the attributes across diff OE-versions, we are leaning towards working-in support for Gramine first.

John & Ye will re-examine use of DCAP interfaces , instead, to get this info.

@jlmucb
Copy link
Collaborator

jlmucb commented Nov 19, 2023

This is complete for Gramine.

@gapisback
Copy link
Collaborator Author

9/25/2024: Revisited ... low-priority; Keep this open for now.

Unlike the things discussed in #87, this item will is SGX-only and will not apply to TDX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants