-
Notifications
You must be signed in to change notification settings - Fork 42
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
Updating CCF PDO/TP Documentation with details about recent API changes used to set PDO contract enclave attestation policy. #475
Changes from 2 commits
105919d
62955bb
fd4bb34
5bea2b8
8ce49e8
9e460ff
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -216,13 +216,33 @@ cd ${PDO_SOURCE_ROOT}/build | |
make test | ||
``` | ||
|
||
## CCF TP TEE attestation policy | ||
## CCF TP TEE attestation verification policy | ||
We briefly describe the attestation verification policy implemented by CCF TP. | ||
- CCF Governance consortium registers attestation policy after TP is deployed. | ||
- Currently, TP supports two policies: | ||
- No attestation verification: This policy is used while using PDO enclaves in SGX SIM mode. | ||
- Check EPID attestation verification reports generated by IAS: This policy is used while using PDO enclaves in SGX HW mode. | ||
- One of the two policies must necessarily have been registered by the CCF consortium before any PDO enclave can be registered. There is no default policy. | ||
CCF TP provides a member-rpc that can be used for registering one of the above two policies. For the second policy above, the consortium | ||
gets to specify expected MREnclave, basename and IAS public key via the member-rpc. | ||
- The policy (including expected value of MREnclave) can be changed anytime by the CCF Governance consortium, subject to voting rules of the consortium. | ||
|
||
1. The TP contains a programmable flag that specifies whether the TP will check | ||
for PDO contract enclaves' attestation when eservices attempt registering | ||
PDO enclaves with TP. The CCF TP governance consortium | ||
(see https://microsoft.github.io/CCF/release/4.x/governance/index.html) | ||
gets to set the flag after the TP is started. The flag can be set only once. | ||
|
||
2. If the flag described above is set, then it is expected that the CCF TP | ||
governance consortium further programs the TP with expected values required to | ||
verify enclave attestation reports. We note that PDO currently supports EPID | ||
attestation verification, and while running in SGX HW mode, the eservice submits | ||
IAS attestation report to the TP as part of contract enclave | ||
registration with TP. To help the TP verify the IAS attestation report, the TP | ||
must be programmed with expected `MREnclave`, enclave `basename` and `ias_public_key`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A couple points worth clarifying: Which of these expected values is unique per contract enclave? What is the actual policy, do these three values need to match for a given contract enclave? And what does the TP do if one/any of these values doesn't match the expectation? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. thank you for the questions. While these are important questions to document, these must be covered as part of PDO/documentation on "how PDO enables HW mode". The TP is one piece of the whole "PDO HW mode flow". A lot of these questions are coming up because we lack documentation on "how PDO supports EPID attestation". I suggest that an issue be created on this topic of the need for extra documentation. otherwise, these are out of scope for this PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Not sure what you mean here. PDO does not enable HW mode. Rather, PDO uses SGX enclaves. The SIM mode is only for whoever wants to experiment on non-SGX platforms.
I don't agree with this. The TP is an architectural component of PDO, and it's actually used in SIM mode too.
As I interpret Marcela's question, the focus is on the values and the policy. About the values, we would have mrenclave and manufacturer certificate even if we used DCAP, so only the basename turns out to have a specific meaning in EPID. Fortunately, we kept things simple, and this makes the answer simple -- I'll add that separately. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My questions are related to EPID attestation verification, but more fundamentally about assumptions-- assumptions about how the system will be used and assumptions about what the reader does and doesn't need to know. This document is quite long and I think the audience is still mostly us, as in, we are documenting this to record our design decisions etc. Does a newcomer user really need all of these details? Many assumptions also aren't documented explicitly, making this document pretty difficult to digest at times. I don't think addressing this should be part of this PR, but it would be good for us to take a step back, put ourselves in the position of a newcomer, and create separate "quickstart" documentation that covers only the most fundamental information and keep this as a longer "deep dive" document.
prakashngit marked this conversation as resolved.
Show resolved
Hide resolved
|
||
Further, the CCF TP governance consortium is permitted to change the | ||
values of these parameters, subject to TP consoritum governance rules. | ||
prakashngit marked this conversation as resolved.
Show resolved
Hide resolved
bvavala marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this desirable behavior? This sentence seems to be implying that the governance consortium can change the expected MRENCLAVE, base name, or IAS key for an existing registered enclave. Why wouldn't a change in these values result in a new enclave registration? That is, a new MRENCLAVE, for all intents and purposes, represents a distinct enclave. Otherwise, wouldn't a verifier with an outdated policy fail upon such changes? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. thank you. same answer as above. |
||
|
||
The TP provides two APIs `set_attestation_check_flag` and `set_expected_sgx_measurements` | ||
to program the various values required to implement the above attestation | ||
verification policy. | ||
Comment on lines
+242
to
+244
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This description is very good, and it says "to program the values". I think we have 3 levels of abstraction here:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the documentation only talks about APIs provided by PDO TP that are useful to implement PDO's attestation policy. How these APIs are used by PDO clients is out of scope of this PR. you can either use the scripts that PDO provides, or write your own scripts. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Precisely, and the scripts are available, and they are even installed ready to be used. |
||
|
||
1. The first API `set_attestation_check_flag` is invoked as part of the TP start up | ||
scripts to specify whether PDO runs in SGX `HW` mode or SGX `SIM` mode. | ||
prakashngit marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
2. The second API `set_expected_sgx_measurements` is used whenever the | ||
`set_attestation_check_flag` specifies that PDO runs in SGX `HW` mode. | ||
In this case, as noted above the second API is used to the specify expected | ||
`MREnclave` value, and additionally `basename` and the `ias_public_key`. | ||
prakashngit marked this conversation as resolved.
Show resolved
Hide resolved
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This flag is set only once per TP instance? This might be helpful to note.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you, yes, only once. again part of policy, must be covered as part of the documentation mentioned above.