Closed AI-Memory closed 3 years ago
@bigdata-memory We want to include a built Graphene-SGX into a docker base image of an application for people to download to build their workspace for the application. If I don't want to include the signing key into the base image, what is the best way for the user who downloads the base image to sign the files for enclaves?
@hanboa Thank you for this question, I think it could be a typical scenario that needs this two-step signing feature. In the production environment, the signing key is rare to be available to use in building environment/workspace, this feature is preferred in this case, basically, it generates signing material first. and then send this material to signing facility because the signing key usually located in that place and strictly protected. once got the signature data, it could continue to complete the whole signing process. please refer to the following one that is excerpted from SGX Developer Reference
p20.
I hope the above is useful for you to apply this process to your working case, thanks.
@hanboa I think your case is completely unrelated to two-step signing, but maybe I'm missing something? What you need is just to ship a container with Graphene installed and probably some stub manifest written and then just let people finish the setup and then build the enclave and sign it.
What @bigdata-memory mentioned is the case where you want to use an HSM or a separate facility for signing, but this sounds unrelated to your problem (you just want to ship some preconfigured Graphene installation).
@mkow Thanks for the comment. In our case, the signer and the enclave runner are separated, so when the enclave runner builds the workspace with the pre-built Graphene-SGX to run their application inside the enclave, it may need the signer who provides the codes to sign the codes for the enclave runner to execute.
@hanboa: Sorry, but I just didn't understand your comment.
@mkow following your comments of "...let people finish the setup and then build the enclave and sign it.". People who finish the setup and build the enclave will need the ISV to sign it.
@hanboa writes:
People who finish the setup and build the enclave will need the ISV to sign it.
First, why is it important that the ISV signs the final enclave in your scenario? Typically, whoever finishes the setup (bundles the prebuilt Graphene-SGX binaries with the application binaries + application manifest) is responsible for signing -- you call these people enclave runners.
Second, if you really want the ISV to sign the final enclave, then why not just:
@dimakuv: This is problematic, I don't think ISV should ever sign the enclave. It has no reasonable way to introspect the bundle and check what's actually being signed, it just gets a bunch of unknown binaries to sign. IMO it always has to be the last party which added/modified something in the enclave.
This was superseded by https://github.com/gramineproject/gramine/issues/11, which is the design we'll implement.
Description of the problem
Currently, Graphene has single step signing feature only which requires the access to the signing key pair on the local build system. However, for production use, the signing key generated by ISV usually is not stored on local build system. therefore, the two-step signing feature is important for platform deployment. for details, please refer to SGX Developer Reference P18
As of now, no official two-step signing support yet, but at this moment, there are two PRs are associated with it, they are PR #2528, #2596.