Attestation API and integration with the PDO build #501

bvavala · 2024-10-19T00:49:11Z

This PR adds the initial implementation of the attestation API (extended from Hyperledger Fabric Private Chaincode) and integrates it with the PDO build.

The attestation API is contained in common/crypto/attestation-api.
Aside from the newly added files, this PR adds 4 modifications to PDO:

it adds 2 new modules used by the attestation API (jwt-cpp for handling jwt tokens and a json library)
it switches one of the builds to be single-threaded due to race conditions which must be debugged
it adds the necessary dependencies, mostly related to DCAP artifacts, to the docker service image
Time to build: a one-liner in the common/crypto/attestation-api does the trick.

mbrandenburger · 2024-10-22T15:23:01Z

This PR is related to #498

cmickeyb · 2024-10-22T15:25:11Z

This PR is also related to #500

g2flyer

A few comments after trying to build and getting the big picture:

doing the Time to build: a one-liner in the common/crypto/attestation-api does the trick. did fail when doing it directly as i was expected to have some dcap repo in /tmp'. That hurdle was crossed by doing the build in docker as in common/crypto/attestation-api/README.md` but then failed later, see errors inline in that README.md
building the overall docker (via make -C docker test) did work but i'm puzzled what was really was built from a pdo-global perspective. Logging (via docker) into pdo_services:0.3.21 i didn't really see anying in the places i would have expected (e.g., /project/pdo/{run,tools} nor was it obvious from looking at the CMakefile (deltas). I'm missing here a bit the big picture: do i just not see anything as this would eventually be all directly backed into the e/p-service binaries/static libraries and as this PR doesn't have any integration yet there is nothing to see? But wouldn't at least the conversion script have to be installed?

So putting it differently:

what should and should not work right now and how am i supposed to test?

build/__tools__/build.sh

docker/pdo_services_base.dockerfile

common/crypto/attestation-api/CMakeLists.txt

common/crypto/attestation-api/LICENSE

common/crypto/attestation-api/README.md

g2flyer · 2024-10-22T15:33:59Z

common/crypto/attestation-api/README.md

+
+DCAP support with ITA is built by default, but requires the URL to the ITA CA root certificates (in JWK format). If the URL is not specified, the build will succeed but it won't be able to verify DCAP attestations.
+```bash
+export ITA_ROOT_CACERT_URL=<certificate url>


where do i find that URL?

You should get that when you subscribe to ITA

You should get that when you subscribe to ITA

How and where do i subscribe? I was expecting some corresponding links here ...

Here https://docs.trustauthority.intel.com/main/articles/howto-manage-subscriptions.html
I think the ITA part should probably stay as is since (1) ITA is not free, (2) this is under a hyperledger project.
Rather, we should focus on the DCAP-direct part, which is free and open.

Here https://docs.trustauthority.intel.com/main/articles/howto-manage-subscriptions.html I think the ITA part should probably stay as is since (1) ITA is not free, (2) this is under a hyperledger project. Rather, we should focus on the DCAP-direct part, which is free and open.

Hmm, but as long as we include the code we still should document it and it's use?

Here https://docs.trustauthority.intel.com/main/articles/howto-manage-subscriptions.html I think the ITA part should probably stay as is since (1) ITA is not free, (2) this is under a hyperledger project. Rather, we should focus on the DCAP-direct part, which is free and open.

Hmm, but as long as we include the code we still should document it and it's use?

More importantly, above link seems for external folks only? Maybe i can log in as intel employee directly in ITA portal but that link to very carefully never have a link for the portal!!

common/crypto/attestation-api/README.md

common/crypto/attestation-api/test/verify_evidence_app_go/main.go

common/crypto/attestation-api/test/conversion_app_go/main.go

bvavala · 2024-10-22T18:28:52Z

building the overall docker (via make -C docker test) did work but i'm puzzled what was really was built from a pdo-global perspective. Logging (via docker) into pdo_services:0.3.21 i didn't really see anying in the places i would have expected (e.g., /project/pdo/{run,tools} nor was it obvious from looking at the CMakefile (deltas). I'm missing here a bit the big picture: do i just not see anything as this would eventually be all directly backed into the e/p-service binaries/static libraries and as this PR doesn't have any integration yet there is nothing to see? But wouldn't at least the conversion script have to be installed?

With this PR you just get the static libraries in build/cmake folder, together with all the other crypto artifacts.
Yes, at some point the conversion scripts will have to be called (presumably) by the eservice -- and thus making the IAS client obsolete. That part has to be worked out.

what should and should not work right now and how am i supposed to test?

Things that should work are: the build, the attestation generation (see how it is used in #502), the attestation API tests (see the related readme to set up the collaterals for testing, or to skip some tests).

cmickeyb

Not reviewing the details of the api implementation; just focused on the integration with PDO.

common/crypto/attestation-api/test/attested_evidence_test.sh

common/crypto/attestation-api/test/conversion_app_go/main.go

common/crypto/attestation-api/common/CMakeLists.txt

cmickeyb · 2024-10-25T21:14:51Z

common/crypto/attestation-api/common/CMakeLists.txt

@@ -8,15 +8,15 @@ SET(JWT_PATCHED_FILEPATH ${CMAKE_CURRENT_SOURCE_DIR}/${JWT_PATCHED_FILENAME} PAR

 ADD_CUSTOM_COMMAND(
 	OUTPUT ${JWT_PATCHED_FILENAME}
-	COMMAND [ ! -f ${JWT_PATCHED_FILENAME} ] && cd jwt-cpp && git apply ../jwt-cpp.patch && touch ../${JWT_PATCHED_FILENAME} || true
+    COMMAND [ ! -f ${JWT_PATCHED_FILENAME} ] && cd jwt-cpp && patch -f -p1 < ../jwt-cpp.patch && touch ../${JWT_PATCHED_FILENAME} || true
 	WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
 	)

 ADD_CUSTOM_TARGET(patch_jwt DEPENDS ${JWT_PATCHED_FILENAME})

 # TODO: devise better strategy for clean up; usually the build folder is removed so the clean is not called
 ADD_CUSTOM_TARGET(clean_patch_jwt


actually what you did with the OUTPUT above should add the file to be cleaned automatically. have you tried "make -C build clean"?

This is tricky because we usually get rid of the build folder. I left a comment that a better strategy is needed for patching/unpatching

build/__tools__/build.sh

cmickeyb · 2024-10-25T21:19:19Z

docker/pdo_services_base.dockerfile

-ARG SGXSSL=3.0_Rev1
+ARG SGX=2.25
+ARG OPENSSL=3.0.14
+ARG SGXSSL=3.0_Rev4



you'll need to rebase to get rid of these.

There is a merge pr waiting for you, Sir!

docker/pdo_services_base.dockerfile

cmickeyb · 2024-10-25T21:21:17Z

docker/pdo_services_base.dockerfile

+ENV DCAP_PRIMITIVES=/tmp/SGXDataCenterAttestationPrimitives
+
+RUN git clone https://github.com/intel/SGXDataCenterAttestationPrimitives.git ${DCAP_PRIMITIVES} \
+    && cd ${DCAP_PRIMITIVES}/QuoteVerification \


why not just have the clone pull the submodules for you?

Is there a way to clone and get the submodules for a specific tag?

docker/pdo_services_base.dockerfile

g2flyer

Ok, made my way now through the many files of fode and after the patch i can now run tests in oaa-properly for DCAP-direct and SIM (epid i assume is as-is from FPC where it was tested and ITA i don't have credentials (besides that apparently the service doesn't work at the moment.

Besides additional inline commes a few more notes on testing

oaa docker test (finally) worked after patch
- tests occasionally but not deterministic reproducably failed but might be due to "underpowered" old FLC NUCs?
- make clean doesn't seem robust when switching SGX_MODE from SIM to HW; required wiping build dir completely to make work
- the test doc could be made more robust by using newer cmake patterns using cmake -S. -B build and then cmake --build build --target test and alike instead of mkdir build, cd, cmake', make` as in principle also should work with other cmake generators, e.g., ninja (or put differently, your instruction will fail if somebody has the CMAKE_GENERATOR env var set.
as code is not integrated in rest of PDO (other than build) i just (a) made sure that make -C docker test still works and (b) did a cursory look into the built pdo_services container to see whether the build of attestation-api was called (which it was)

common/crypto/attestation-api/attestation/attestation.cpp

g2flyer · 2024-10-25T16:45:41Z

common/crypto/attestation-api/attestation/dcap.cpp

+ * C prototype declarations for the ocalls
+ * *******************************************************************************************************************/
+
+#ifdef __cplusplus


These things would probably best handled in separate .h files? I'm also surprised that SDK doesn't have already these wrappers?

common/crypto/attestation-api/attestation/dcap.cpp

common/crypto/attestation-api/common/CMakeLists.txt

common/crypto/attestation-api/common/Makefile

g2flyer · 2024-10-25T17:19:12Z

common/crypto/attestation-api/conversion/dcap-direct/b64attestation2b64collateral.cpp

+        memcpy(p+sizeof(sgx_ql_qve_collateral_t)+c->pck_crl_issuer_chain_size+c->root_ca_crl_size+c->pck_crl_size, c->tcb_info_issuer_chain, c->tcb_info_issuer_chain_size);
+        memcpy(p+sizeof(sgx_ql_qve_collateral_t)+c->pck_crl_issuer_chain_size+c->root_ca_crl_size+c->pck_crl_size+c->tcb_info_issuer_chain_size, c->tcb_info, c->tcb_info_size);
+        memcpy(p+sizeof(sgx_ql_qve_collateral_t)+c->pck_crl_issuer_chain_size+c->root_ca_crl_size+c->pck_crl_size+c->tcb_info_issuer_chain_size+c->tcb_info_size, c->qe_identity_issuer_chain, c->qe_identity_issuer_chain_size);
+        memcpy(p+sizeof(sgx_ql_qve_collateral_t)+c->pck_crl_issuer_chain_size+c->root_ca_crl_size+c->pck_crl_size+c->tcb_info_issuer_chain_size+c->tcb_info_size+c->qe_identity_issuer_chain_size, c->qe_identity, c->qe_identity_size);


uff, this p+a+b+c... construct looks very brittle (and tedious). I think a running pointer and an increment after each field would be much better ...

For the same brittleness reason i would also put the deserialization (now in verify_dcap_direct) together with the serialization in the same file (presumably as a new package in common ...

I agree, and unfortunately the dcap library does not provide that. Actually, when it returns the collateral as a uint8_t*, that's an opaque pointer to the data structure, not to the serialized buffer :(

Hmm, i'm confused why refactoring our (de)serialization code into a single place (separate package) and using the less brittle pattern size=sizof(nextfield); memcpy(moving_ptr, next_field, size); moving_ptr+=size; has anything to do with what the dcap library provides? (of course, it would have been nice if dcap library would already have provided (de)serialization but that's besides my point?)

I think the update addresses your comment

g2flyer · 2024-10-25T17:25:24Z

common/crypto/attestation-api/evidence/verify-ias-evidence.cpp

@@ -0,0 +1,240 @@
+/*


i would name this by the attestation type rather than with ias in the name ...

Thanks for the suggestion. I admit that a discussion on naming conventions can be helpful. For instance, although I made some decisions regarding DCAP (ITA/Direct), the attestation generation is one (and should have one type), while the attestation verification should have two types.

g2flyer · 2024-10-25T17:29:55Z

common/crypto/attestation-api/evidence/verify-evidence.cpp

+        0 == attestation_type.compare(EPID_UNLINKABLE_TYPE_TAG))
+    {
+        ByteArray ba_evidence(evidence_field.begin(), evidence_field.end());
+        bool b = verify_ias_evidence(ba_evidence, ba_expected_statement, ba_expected_code_id);


given that attestation_type is not passed to verify_ias_evidence: where/how do we verify that the evidence had the correct epid type?

The type check is only done at line 57. Later, either the evidence has the correct epid type, or it will fail the verification.

Not sure i understand 100%. Do we not care in PDO what attestation type is used? Or put differentlly, the only thing we care is that there is some valid attestation, regardless whether it is linkable EPID, unlinkable EPID or DCAP? I thought previously it was crucial that we had linkable EPID? I would have expected that when verifying evidence we would pass an expected attestation type ...

Oh, now I got your question.
There are two ways:

as I show in the next PR (see signup.cpp line 141), we can force the contract enclave to generate (or to check that it is generating) a linkable EPID quote, which will be reflected in the MRENCLAVE. So, later, if you have the right mrenclave, the verification is correct.

the second way is to check for the the "epidpseudonym" field in the report -- this is optional and only present for linkable signatures.

We could:

either rely on (1),

or add the epidpseudonym check at verification time,

or simply leave this epidpseudonym check to the policy appraisal (which is not implemented here, and should also include the debug-disabled check among others).

Oh, now I got your question. There are two ways:

as I show in the next PR (see signup.cpp line 141), we can force the contract enclave to generate (or to check that it is generating) a linkable EPID quote, which will be reflected in the MRENCLAVE.

This is code outside of enclave: why would that result in different MRENCLAVE depending on attestation type?

So, later, if you have the right mrenclave, the verification is correct.
2. the second way is to check for the the "epidpseudonym" field in the report -- this is optional and only present for linkable signatures.

We could:

either rely on (1),

or add the epidpseudonym check at verification time,

or simply leave this epidpseudonym check to the policy appraisal (which is not implemented here, and should also include the debug-disabled check among others).

My comment was originally just starting from an API perspective and my expectation would have been that there would be an a boolean flag linkable. But you bring up epid-pseudonym of course is a good point. but as pseudonym is apriori not known, my api proposal would have been to add the boolean flag as input and have an optional outparam which for linkable would return the pseudonym. That said, at this point with EPID not really worth changing (but then my designer head cannot resist and i was actually also looking at options for PQC-equivlants of EPID (or at least DAA). There actually would be some options and they would satisfy the IETF IAB but alas very unlikely that intel would ever pick that up unless NIST would ....

This is code outside of enclave: why would that result in different MRENCLAVE depending on attestation type?

You're right that the code I linked is outside of the enclave.
However, the attestation generation (get_attestation) is inside the enclave.
So, what I meant is to have a check right there to enforce that the attestation being generated is of type epid-linkable, as defined in the usage document.

but as pseudonym is apriori not known

Right, but the "field" is in the report and signed by IAS. So you just have to check that it is present in this case.
And, again, this can be one of the conditions in a policy appraisal -- which should be implemented anyway.

common/crypto/attestation-api/evidence/verify-dcap-direct-evidence.cpp

g2flyer · 2024-10-25T21:47:42Z

common/crypto/attestation-api/evidence/verify-dcap-direct-evidence.cpp

+    ByteArray certification_data;
+    uint32_t certification_data_size;
+    uint16_t certification_data_type;
+    ByteArray collateral;


These vars seem to be used only in verify block, so why not declare them there? Makes it easier when reading code to see var definitions ...

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

…d build (for later troubleshooting), (2) removes the dead Go code in the attestation lib, (3) it removes duplicate packages in the services dockerfile, (4) it add the reason for doing a double build of the DCAP primitives Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

…s not a standalone repo anymore -- thanks michael for spotting this Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

…l that from pdo docker build Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

mbrandenburger

LGTM

bvavala requested a review from cmickeyb October 19, 2024 00:49

bvavala assigned cmickeyb Oct 19, 2024

bvavala requested a review from g2flyer October 19, 2024 00:50

bvavala mentioned this pull request Oct 19, 2024

Using the attestation generation capability of the new attestatation API inside the eservice enclave #502

Draft

cmickeyb requested a review from mbrandenburger October 22, 2024 15:24

g2flyer reviewed Oct 22, 2024

View reviewed changes

g2flyer mentioned this pull request Oct 23, 2024

Time provisioning inside PDO enclaves #500

Open

cmickeyb requested changes Oct 25, 2024

View reviewed changes

g2flyer reviewed Oct 25, 2024

View reviewed changes

bvavala force-pushed the bruno.241017.move-to-attestation-api branch from bd6e0fe to 12864aa Compare November 5, 2024 22:50

bvavala added 10 commits November 14, 2024 21:27

add attestation api to pdo build

f36b4bf

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

remove makefile and update readme in attestation api

85c3b30

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

switching from git apply patch to patch because the attestation api i…

e2827c3

…s not a standalone repo anymore -- thanks michael for spotting this Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

attestation api usage document

4d1391a

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

provide citation for jwt-cpp patch

0b1175f

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

some indentation; remove cmake; tidy up some variable definitions

98d949d

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

simplify dcap installation, switching completely to 1.22

ae2b251

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

move attestation api dependencies for pdo to separate script, and cal…

da9375d

…l that from pdo docker build Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

fix indentation

c1cf654

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

bvavala force-pushed the bruno.241017.move-to-attestation-api branch from 12dcb77 to c1cf654 Compare November 14, 2024 21:29

refactor serialize collateral

d9eefcb

Signed-off-by: Bruno Vavala <bruno.vavala@intel.com>

g2flyer self-requested a review November 15, 2024 01:40

g2flyer approved these changes Nov 15, 2024

View reviewed changes

cmickeyb approved these changes Nov 19, 2024

View reviewed changes

mbrandenburger approved these changes Nov 26, 2024

View reviewed changes

bvavala mentioned this pull request Dec 17, 2024

First commit with attestation API from PDO's pull request #501 LF-Decentralized-Trust-labs/one-attestation-api#1

Open

cmickeyb merged commit 33e6295 into hyperledger-labs:attestation-dev Dec 17, 2024
5 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Attestation API and integration with the PDO build #501

Attestation API and integration with the PDO build #501

bvavala commented Oct 19, 2024

mbrandenburger commented Oct 22, 2024

cmickeyb commented Oct 22, 2024

g2flyer left a comment •

edited

Loading

g2flyer Oct 22, 2024

bvavala Oct 22, 2024

g2flyer Oct 22, 2024

bvavala Oct 23, 2024

g2flyer Oct 23, 2024

g2flyer Oct 23, 2024

bvavala commented Oct 22, 2024

cmickeyb left a comment

cmickeyb Oct 25, 2024

bvavala Nov 5, 2024

cmickeyb Oct 25, 2024

bvavala Nov 5, 2024

cmickeyb Oct 25, 2024

bvavala Nov 5, 2024

g2flyer left a comment

g2flyer Oct 25, 2024

g2flyer Oct 25, 2024

bvavala Nov 5, 2024

g2flyer Nov 8, 2024

bvavala Nov 15, 2024

g2flyer Oct 25, 2024

bvavala Nov 5, 2024

g2flyer Oct 25, 2024

bvavala Nov 5, 2024

g2flyer Nov 8, 2024 •

edited

Loading

bvavala Nov 15, 2024

g2flyer Nov 15, 2024

bvavala Nov 15, 2024

g2flyer Oct 25, 2024

mbrandenburger left a comment

Attestation API and integration with the PDO build #501

Attestation API and integration with the PDO build #501

Conversation

bvavala commented Oct 19, 2024

mbrandenburger commented Oct 22, 2024

cmickeyb commented Oct 22, 2024

g2flyer left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvavala commented Oct 22, 2024

cmickeyb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

g2flyer left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

g2flyer Nov 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mbrandenburger left a comment

Choose a reason for hiding this comment

g2flyer left a comment •

edited

Loading

g2flyer Nov 8, 2024 •

edited

Loading