scrtlabs / SecretNetwork

𝕊 The Secret Network
https://scrt.network
Other
529 stars 199 forks source link

Reproducible builds for enclave binaries #1467

Open sbellem opened 1 year ago

sbellem commented 1 year ago

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 andtendermint_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 commented 1 year ago

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 commented 1 year ago

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.