WIP: Add ISV product ID and ISV SVN fields to manifest

[DL8]

ISV product ID and ISV SVN fields are defined and signed in SIGSTRUCT. In Gramine, they are defined in the manifest and then used on enclave signing in enclave build flow. Add the option to configure them in OpenFL manifest with new flags to the makefile: SGX_ISVPRODID and SGX_ISVSVN. Their default values are 0, to maintain backwards compatibility.

Currently ISV SVN is configurable in build time, but this is not necessarily the desired behavior. Required behavior is open for discussion and should be updated once a decision is made.

Related issue: #501

[github-actions[bot]]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[DL8]

I have read the CLA Document and I hereby sign the CLA

[DL8]

recheck

[igor-davidyuk]

Thank you for your contribution! I must note that no example in https://github.com/gramineproject/examples feature these fields in manifests and the related section in Gramine docs is rather humble. Thus it is unclear how developers can come up with relevant product ID numbers and automate manifest versioning.

[DL8]

Thank you for your contribution! I must note that no example in https://github.com/gramineproject/examples feature these fields in manifests and the related section in Gramine docs is rather humble. Thus it is unclear how developers can come up with relevant product ID numbers and automate manifest versioning.

I guess the ISV product ID and SVN are not an important detail in Gramine examples, so zero is used implicitly. They are mentioned in the samples of Intel's SGX SDK, but I looked at some of them and they used zeroes.

More information about those fields can be found here. Quote (emphasis is mine):

Each enclave is associated with a SIGSTRUCT structure, which is signed by its author and contains the enclave measure, signer public key, version number (ISV, reflecting the security level) and product identifier (ISVPRODID, to distinguish between enclaves from the same author). It allows to ensure that the enclave hasn't been modified and then re-signed with a different key.

As I understand it, product ID convention is up to enclave developer. Assigning each enclave with a different number (e.g. 1 for server and 2 for client) is a good approach. Once chosen, I don't see any reason to change it. I don't understand what is manifest versioning. Do you mean ISVSVN? This is not manifest version, but enclave security version. It should start with zero and increment when a security vulnerability is fixed (not 100% automatic).

[igor-davidyuk]

Thank you for the detailed explanation, @DL8 We can start incrementing ISVSVN on our side. Another idea is to bind this number to the OpenFL version, as it is the main application running inside our enclave, do you think it is a good idea?

[DL8]

@igor-davidyuk you shouldn't increment ISVSVN with every version, but only in case the new version includes security vulnerability fixes. Also, if the SVN was incremented, it should be mentioned in the release notes

[igor-davidyuk]

Ok then, seems like there is nothing to add to this PR. Are you going to remove WIP?

[DL8]

If you believe this is the right way to implement this, I will remove the WIP