2FA zk-rollups using SGX

Following assumes that attacks against SGX can steal bits of private key, but only at rate of few bits per privkey access. And privkey is accessed only to produce signatures.

Consider rotating the keypair with every attestation. Add pubkey of the new keypair to the tuple signed on every attestation: (pre_state_root, post_state_root, block_root, new_pubkey). Smart contract will update 2FA key with new_pubkey.

This increases gas cost - one more SSTORE per state transition.

6 Likes

If there was a critical failure of SGX (worst case scenario you can imagine, including Intel being actively malicious), what bad things would happen? Assuming the ZK stuff was not broken then would nothing bad happen at all? Is the bad scenario only when both SGX and ZK stuff are broken?

One disadvantage of this is that you don’t get the benefit of an escalating “bug bounty” over time as the system attracts capital. The set of attackers who can exploit a bug in the ZK stuff is limited to state actors, Intel, and maybe some hardware manufacturers involved in the chip production process. This means everything seems to be fine right up until it catastrophically fails and that could be a long way off. If the ZK is exposed directly, it is more likely to be attacked early before too much capital moves in.

7 Likes

Oh, great suggestion! :slight_smile:

There is no dependency on SGX—that’s the point. When SGX is breached safety falls back to a “vanilla” zk-rollup. SNARKs plus SGX is a strict safety improvement over just SNARKs.

Yes to both questions.

In addition to the “organic” bug bounty for simultaneously breaking both the SNARK and SGX, one could design a “synthetic” escalating bug bounty for breaking either the SNARK or SGX. The synthetic bounty could escalate by, say, 10 ETH per day.

The endgame for zk-rollups is that SNARKs are sufficient for security thanks to multi-proofs (see links in the post) and formal verification. You can think of SGX security-in-depth as a way to buy time to achieve this endgame and reduce the risk of ever failing catastrophically.

8 Likes

ORs often get criticized for this ability because arguably it means that users have to trust the governance mechanism first and foremost and the fraud proofs are not much more than decoration. Wouldn’t SGX 2FA be a great tool for ORs to minimize the power of governance? Emergency updates would only be allowed if there’s disagreement between the two factors. Other updates would require a notice period of about one month, giving everyone ample time to exit if they disagree.

5 Likes

Setup a 2FA Network/Layer: this should verify the 2FA proofs required by the protocol. The nodes could be run on low-cost hardware (e.g. Raspberry Pis) and could be distributed geographically to ensure redundancy and resilience.

Aaggregated Proof: Also, the protocol could use proof aggregation techniques to minimize the overhead of generating and verifying 2FA proofs. This involves grouping multiple proofs together and creating a single, aggregated proof that can be verified more efficiently. Certainly, this will need to be designed to secure and resist attack.

2 Likes

What if we would move the remote attestation off-chain? Do you see any scenarios where it would make rollups less secure?

The rollup could serve the remote attestation via a different channel upon request, allowing any user interested in interacting with the rollup to verify its attestation (and that it is the owner of privkey). Since the smart contract verifies signatures generated by SGX, full trust is established.

Even key rotation could be implemented by the rollup, by just creating and storing the remote attestation of every key used.

2 Likes

This will certainly reduce gas costs, but I can see some tradeoffs:

  1. Since this involves safeguarding privkey, this approach is vulnerable if SGX’s confidentiality is broken and privkey is ever extracted and used to sign bad state roots. Instead, verifying an SGX remote attestation on-chain per state root requires breaking SGX’s integrity to produce a bad state root (but also requires way more gas).
  2. This approach seems to lend itself better to a permissioned rollup, where the sequencer controls which (key, remote attestation) pairs are whitelisted by the contract. The verify-before-use idea breaks down if we want > 1 sequencer per rollup.
  3. More burden on the users - they could join a nefarious rollup if they are lazy and skip the off-chain verification.
2 Likes

It’s a quite nice use case of SGX for fair execution not for storing private keys. With guaranteed execution, it helps both Optimistic and ZK rollups for verification.

2 Likes

I believe we can combine both approaches.

  1. a sequencer introduces itself to the contract with a remote attestation that also attests it and its private key have been created very recently (i.e. add latest known block hash before priv key generation to attestation quote)
  2. the sequencer will publish new state roots and regenerate its private key every now and then (as per @pepesza 's suggestion)
  3. if the delta between two private key switches is to big, the contract will dismiss sequencer submissions
  4. A new sequencer can be introduced as per step 1

This reduces gas costs as we’re only attesting during sequencer registration, But at the same time it should allow > 1 sequencer per rollup - as per your definition.

1 Like

I believe this can be taken even further and we can do a remote attestation (RA) + key-rotation per state root while only paying L2 gas fees!

  • The sequencer performs RA, committing to a fresh ETH public key and the last block hash.
  • The sequencer verifies the RA as part of the batched rollup txs (paying only L2 gas fees for on-chain RA verification). The ETH public key becomes whitelisted, assuming the RA was valid and the committed last block hash is sufficiently fresh.
  • The L1 contract will only accept the state root if it was signed with the enclave’s corresponding ETH private key, otherwise it will revert (this relies on the rollup’s data being immediately available to the L1).
3 Likes

Interesting approach!

  • if RA is not trivial to implement in vanilla EVM, zkEVM’s might have more implementation issues and zk-rollups which do not have EVM compatibility will likely have even more issues doing RA?
  • if we have a setup where the rollup uses the TEE block transition proof as the only source of truth, then the enclave providing the RA would be the one verifying it’s correctness, which brings no gain (TEE only rollups have not really been discussed so far but are an interesting topic nonetheless)
  • in addition to that - if the zk proof can be faked I think the RA can be faked as well, so we would be loosing the 2FA guarantees
3 Likes

The pubkey is registered on-chain by verifying an SGX remote attestation which attests to the pubkey being correctly generated.

This step would interest me the most on how this would be (is?) implemented in detail…
Where is the attestation report + collateral stored for later verification by 3rd parties?
I guess the attestation report_data will contain the hash of the pubkey.

I doubt EVM could do a full attestation verification with all the TCB state verification and certificate revocation lists involved, but prove me wrong :slight_smile:

1 Like

It turns out I was wrong! Verifying the SGX remote attestation can be done offchain by users :slight_smile: This makes SGX 2FA easy to implement.

1 Like

Where is the attestation report + collateral stored for later verification by 3rd parties, then?

1 Like

The SGX attestation can be hosted anywhere (e.g. on a traditional website, on IPFS, even on-chain).

Not sure what collateral you are referring to. The scheme described doesn’t have collateral.

1 Like

The scheme described doesn’t have collateral.

To completely verify an attestation report you need additional data from api.trustedservices.intel.com (see Intel® Trusted Services API Management Developer Portal).

So a report with the collateral downloaded at the time of attestation, you need (bytes from an example report + collateral from this week):

  • the report itsself (4730 bytes)
  • collateral.pck_crl (3653 bytes)
  • collateral.pck_crl_issuer_chain (1905 bytes)
  • collateral.tcb_info (4291 bytes)
  • collateral.tcb_info_issuer_chain (1893 bytes)
  • collateral.qe_identity (1381 bytes)
  • collateral.qe_identity_issuer_chain (1893 bytes)
  • collateral.root_ca_crl (448 bytes)

Which would sum up to: report 4730 bytes + collateral 15464 bytes = 20194 bytes for one of my TEEs as of this week.

Then you have to define and record somewhere what TCB status is still acceptable, like “SWHardeningNeeded” and which advisory Ids the SGX software mitigates like “INTEL-SA-00615”.

2 Likes

@JustinDrake this seems like a really cool idea for a thesis/paper, would love to pursue it if possible. What’s the best place to contact you?

2 Likes

Oh I see, “collateral” is some subset of the attestation data :slight_smile: (For me “collateral” usually means financial collateral.)

To answer your question: the attestation data (report + collateral) can be stored anywhere—that’s an implementation detail. It just needs to be downloadable by prospective users.

2 Likes

This point is very interesting, and to expand on it I think a multisig or TSS involving multiple enclave vendors could add an additional layer of security, arguably even 3FA.

Especially combined with this, I imagine it is significantly difficult or at least prohibitively expensive to attack multiple architectures and in the span of a single transaction.

There are attacks which can fake attestations of bad enclaves, so I don’t think key rotation alone would prevent those on a single architecture, but I’m not sure how easy it is to perform such attacks on multiple enclave architectures at once before one patches it.

This seems strictly better than a SNARK alone, especially with

  • enclaves from multiple vendors in a multisig
  • rotating keys every transaction
1 Like

I think in general for any use cases that focuses on integrity more than confidentiality, then the more alternate implementations, the better, because each implementation provides an additional check. N-of-N comprises are needed basically.

However, if only 1-of-N compromises are required (say in certain types of designs that focuses on confidentiality) where a single compromise would result in the secret leaking, then more might not be better.

1 Like