Request for Feedback: Migrating from MRSIGNER to MRENCLAVE sealing

Secret Network
1

Hi all :wave:,

SCRT Labs is seeking feedback on a proposed a new design for the consensus seed sealing mechanism on Secret Network. This design would move away from using MRSIGNER for sealing the consensus seed to using MRENCLAVE. The goal of this change is to further decentralize Secret Network.

Background

MRENCLAVE

The MRENCLAVE (Measurement of Enclave) in SGX is calculated using a SHA-256 hash of the enclave unsigned binary. The enclave unsigned binary is the compiled code of the enclave, which is the trusted part of an SGX application.

To calculate MRENCLAVE, the enclave binary is first divided into 4096-byte chunks. Each chunk is then hashed using SHA-256. The hashes of all the chunks are then concatenated to form the final MRENCLAVE.

The MRENCLAVE is a unique identifier for the enclave binary. It can be used to seal confidential data that can be unsealed only by an enclave with the same MRENCLAVE.

MRSIGNER

The MRSIGNER (Measurement of the Signing Key) in SGX is calculated using a SHA-256 hash of the enclave’s developer public key.

To calculate MRSIGNER, the enclave’s developer public key is first converted to a byte string. The byte string is then hashed using SHA-256. The hash is the final MRSIGNER.

The MRSIGNER is a unique identifier for the enclave’s developer public key. It can be used to seal confidential data that can be unsealed only by an enclave with the same MRSIGNER.

Secret Network

In 2020, SCRT Labs decided to use MRSIGNER to seal the consensus seed. This means that for every version of Secret Network, SCRT Labs has signed the enclave with its private key.

The main reason for choosing MRSIGNER is that it made upgrading the chain easy. If SCRT Labs had opted to use MRENCLAVE, we would have also needed to implement a handover mechanism to send the consensus seed from the old enclave to the new enclave every time the chain is upgraded.

EDIT: To emphasize, sealing with MRENCLAVE was significantly more difficult to implement and would have introduced potential risks that could have been fatal for the network without also implementing proper mitigations (which will be discussed later in this post). All of this would have delayed the mainnet release of Secret Network by at least 6 months, possibly a year.

The main challenge with using MRENCLAVE is the need for a proof system inside the enclave. This is to ensure that the new enclave is approved by the network and that the old enclave is not sending the consensus seed to a malicious enclave.

As of October 2023 (including v1.12), SCRT Labs has not yet implemented that proof system inside the enclave. Any solution that uses MRENCLAVE for consensus seed sealing would also require that proof system to be implemented inside the enclave first.

Proposed Design

  1. There will be a proof system inside the enclave, that can verify the chain’s state using merkle proofs.
  2. There will be two new on-chain params: current_mrenclave & next_mrenclave.
  3. We’ll modify the upgrade proposal to also include a new next_mrenclave param and change it if the proposal passes.
  4. The upgrade handler would update next_mrenclave and then trigger a “migrate consensus seed workflow” inside the old enclave.
  5. The old enclave would read current_mrenclave & next_mrenclave from the chain and verify both with merkle proofs, secured by the enclave’s light client (I.e., signed by >2/3 of validators).
  6. The old enclave would check that current_mrenclave matches its own identity.
  7. The old enclave would perform a local attestation for the new enclave binary and check that the next_mrenclave parameter matches the new enclave’s identity.
  8. The old enclave would use a local communication scheme (TBD, can be local socket, HTTPS, etc.) to send the seed from the old enclave to the new enclave. This can be done using the same encryption protocol that is currently used for sending the seed to new nodes.
  9. The new enclave would seal the seed with MRENCLAVE.
  10. The new enclave would update the on-chain parameter current_mrenclave = next_mrenclave.
  11. The chain would resume producing blocks with the new enclave.

We will require at least two upgrades to reach the final state. The first upgrade will introduce the code that allows the old enclave to verify the new enclave and send the consensus seed. The second upgrade will allow the new enclave to receive the consensus seed and enable MRENCLAVE sealing.

Seed Recovery and Safety Mechanisms

In case of a bug in the handover mechanism, the chain could reach a limbo state where the old enclave cannot verify the new enclave or send the consensus seed. To address this issue, we will add a way to allow a specific MRENCLAVE to read the consensus seed by introducing a special transaction type that is signed by SCRT Labs in addition to all or most of the validators.

EDIT: This mechanism isn’t fully fleshed out yet, but the goal is to add a way to send the consensus seed to a new enclave without going through governance, in case the chain is halted.

Additionally, to prevent a governance attack or bug, we are considering adding the requirement that SCRT Labs vote yes on an upgrade proposal in order for it to pass. At least for the first few upgrades, until everyone is more comfortable with the new process.

Pros & Cons

Pros:

  • SCRT Labs will no longer be able to decrypt the entire state at will (not that we ever did).
  • Given a reproducible build setup, anyone will be able to compile and run their own binaries on mainnet. Currently, only SCRT Labs can compile the SGX enclave because it requires our developer key for MRSIGNER sealing to work on mainnet.

Cons:

  • Upgrades will become more dangerous, because if there is a bug in the consensus seed handover mechanism implementation, no one will be able to compile a version that fixes it. To mitigate this risk, the proposed design will gradually migrate from MRSIGNER to MRENCLAVE over multiple chain upgrades to ensure that the mechanism and implementation are sound.

Feedback

SCRT Labs would like to receive community feedback on this proposed design. We welcome any questions, notes, insights regarding the proposed design, pros, cons, seed recovery, safety mechanisms, or anything else. :pray:

We are very excited about this proposal and see it as a huge leap forward for Secret Network in terms of maturity and decentralization. :star_struck:

14 Likes
2

Edited in two places to clarify some subjects.

3

Bravo & huzzah! This has been a critique of Secret for too long

2 Likes
4

Great work :+1:

Sounds great and is more than worth it.

It’s clear to me that these are critical issues that need to be addressed, without which it would be very difficult to convince large companies or institutions.

2 Likes
5

Can you comment on why or WHO has requested migrating from MRSIGNER ?

1 Like
7

It was probably being discussed within the community before this too, but I think Andrew Miller brought a lot of awareness to it back in March Tradeoffs Discussion: Upgrade Transparency

1 Like
8

Supported. A long needed step towards better privacy.

3 Likes
9

This plan looks great imo! Just to contribute two reactions:

I wonder how this backup mechanism can be made simpler than the main mechanism, in particular determining who exactly are all or most of the validators requires the light client functionality anyway?

Second thought: a possible additional feature would be for contracts to opt in or out of migration to a new mrenclave. This could allow applications to defend themselves against even a majority of the validators and devs from rugging their privacy. This would probably require more complicated key derivation than what’s used currently but just want to note the possiblity

4 Likes
10

That’s already implement and available inside the enclave. In addition to that we’ll probably need to hard-code SCRT Labs’ public key inside the enclave.

That’s a very interesting idea! In theory the new enclave can do whatever it wants if it has the consensus seed, so I think we’ll need to completely change the way state encryption works in order to make that possible.

1 Like
11

Cool! I’ll follow up in another thread, don’t want to distract from feedback on this very pragmatic proposal here. But it’s a great research topic, the most relevant basic concept is puncturable encryption which let’s you drop portions of the decryption capability of the key. Like the ordinary consensus seed is the root of a tree, individual contracts are leaves, and dropping capabilities is like deleting the root but only keeping roots of subtrees off path from the one you want to delete.

3 Likes