Giters

gramineproject / graphene

Graphene / Graphene-SGX - a library OS for Linux multi-process applications, with Intel SGX support

Home Page:https://grapheneproject.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

RFC: Two-step signing feature

bigdata-memory opened this issue · comments

commented

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.

commented

@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?

commented

@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.
image
I hope the above is useful for you to apply this process to your working case, thanks.

commented

@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).

commented

@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.

commented

@hanboa: Sorry, but I just didn't understand your comment.

commented

@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.

commented

@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:

  1. The enclave runner prepares the bundle <Graphene-SGX binaries + application binaries + application manifest>.
  2. The enclave runner sends this bundle to the ISV signer.
  3. The ISV signer signs this bundle (final enclave) -- the result of this signing process is the SIGSTRUCT file.
  4. The ISV signer sends the SIGSTRUCT file to the enclave runner.
  5. The enclave runner inspects the MRENCLAVE and possibly other fields in SIGSTRUCT to make sure MRENCLAVE correctly reflects the bundle that the enclave runner sent to the ISV in step 2.
  6. Now we have two artifacts:
    • The bundle (final enclave) prepared by the enclave runner
    • The SIGSTRUCT file prepared by the ISV signer
commented

@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.

commented

This was superseded by gramineproject/gramine#11, which is the design we'll implement.