Skip to content
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

Reproducible builds for enclave binaries #1467

Open
sbellem opened this issue Jun 20, 2023 · 2 comments
Open

Reproducible builds for enclave binaries #1467

sbellem opened this issue Jun 20, 2023 · 2 comments

Comments

@sbellem
Copy link
Contributor

sbellem commented Jun 20, 2023

Opening this issue as an entry point to discuss the implementation of whatever is necessary to provide reproducible builds for enclave binaries (librust_cosmwasm_enclave.signed.so and tendermint_enclave.signed.so`).

The underlying assumption is that it is potentially a desired goal, judging from the README.md text under https://github.com/scrtlabs/SecretNetwork#build-from-source:

For a production build the enclave must be copied from the most recent release.

This is due to non-reproducible builds, and the fact that enclaves must be signed with a specific key to be accepted on mainnet.

Still, the non-enclave code can be modified and ran on mainnet as long as there are no consensus-breaking changes

The two main benefits of having reproducible builds would be:

  1. Possibility for anyone to easily verify that enclave binaries match the source code.
  2. Possibility for node runners to use enclave binaries built from source as opposed to downloading them from a trusted source. (This would obviously require using the MRENCLAVE sealing policy.)
@assafmo
Copy link
Member

assafmo commented Jun 21, 2023

It's non-reproducible because the binary is signed using SCRT Labs' private key. It is reproducible if we use the same private key. IMO the next step to gain more trust is to migrate to a new multisig private key, but that is a huge undertaking as you have to also reencrypt the entire encrypted state.

@sbellem
Copy link
Contributor Author

sbellem commented Jun 22, 2023

Hey, thanks for providing feedback!

Regarding the topic of verifying whether an enclave binary matches some source code, as far as I understand, if the code hasn't changed (i.e. same commit hash) and the toolchain to build the enclave binary yields bit-for-bit reproducible builds, then the enclave hash (aka MRENCLAVE) should remain the same regardless of the signing key (modulus). In other words, different signing keys will yield different MRSIGNERs and different (unsigned) enclave binaries will yield different MRENCLAVEs.

The MRSIGNER and MRENCLAVE are totally independent of each other.

For instance, given a signed enclave binary, the sgx_sign tool can extract the SIGSTRUCT which contains both the enclave_hash and key modulus. (ref)

Example: getting the MRENCLAVE of librust_cosmwasm_enclave.signed.so v1.9.2:

sgx_sign dump -enclave librust_cosmwasm_enclave.signed.so -cssfile enclave_css -dumpfile /dev/null
>>> import struct
>>> with open('enclave_css', 'rb') as f:
...     sigstruct = f.read()
... 
>>> bytes(struct.unpack_from("<32B", sigstruct, 960)).hex()
'7658396785d7a041e502ca8ec194fd513abffc8aea88426ca687b86ad6df5388'

To verify whether a signed enclave binary matches some source code, one can just rebuild the enclave binary from the source code and sign it with a dummy key and use the sgx_sign tool to dump the SIGSTRUCT to a file and then extract the MRENCLAVE out.

This works as long as the enclave binary can be rebuilt from source, bit-for bit, hence the motivation for reproducible builds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants