Evaluate alternatives to `gramine-sealing-key-provider`

[pbeza]

Background

The current design relies on gramine-sealing-key-provider to derive the key for CVM encryption (and possibly for encrypting the backed-up keyshares in the TEE-based migration service), but it’s starting to feel like a code smell for several reasons:

1. Gramine itself is no longer actively maintained.
   The project name suggests it uses Gramine under the hood, and based on first-hand info, Gramine is effectively unmaintained.
2. TDX deprecated storage sealing
   TDX dropped support for sealing (which gramine-sealing-key-provider essentially tries to re-implement) after multiple potential replay-attack surfaces were identified. See:
   • https://collective.flashbots.net/t/loose-seal-enabling-crash-tolerant-tdx-applications-by-utilizing-sgx-sealing-provider-sidecar/4243
   • https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-matetic.pdf
3. gramine-sealing-key-provider repo looks like a PoC rather than a production component.
   It has 13 stars, 9 forks, and 3 followers, and appears tightly tied to a blog post rather than a mature, maintained project.
4. It’s probably unaudited, yet we treat it as a security-critical part of our system.
   This situation feels very “XKCD 2347” — the entire system leaning on a tiny, fragile package.
   

Given all that, we should evaluate whether to continue relying on gramine-sealing-key-provider. A more robust long-term option might be a fully-fledged KMS running inside the TEE.

Since we already depend on gramine-sealing-key-provider for MPC node disk encryption, we can probably keep using it for the migration service for now, but ideally replace it after the hard launch.

User Story

As an MPC network user, I don’t want to rely on sketchy projects that play a security-critical role in the system.

Acceptance Criteria

• A clear proposal is written outlining alternatives to gramine-sealing-key-provider (e.g. TEE-based KMS, deterministic CKD-derived encryption keys, or other TDX-native approaches).
• The proposal includes:
  • Pros/cons of each alternative.
  • Security implications (e.g. replay-attack resistance, reliance on attestation, auditability).
  • Operational complexity and migration costs.
• The team reaches a decision on whether to:
  • Continue using gramine-sealing-key-provider temporarily and replace it later, or
  • Replace it before hard launch.
• If we decide to replace it:
  • A follow-up issue is created describing the implementation plan.
• If we decide to keep it temporarily:
  • Risks, assumptions, and the timeline for replacing it post-launch are documented.

Resources & Additional Notes

https://nearone.slack.com/archives/C07UW93JVQ8/p1763031771847869?thread_ts=1763028955.961159&cid=C07UW93JVQ8

[gilcu3]

Although I agree that if gramine is unmaintained we should migrate from it in the long term, the fully-fledged KMS alternative you mention does not seem to be in a much better state:
This plugin has not yet received an audit. Use at your own risk.

Not sure about how maintained it is (they have very few commits this year for example)

[pbeza]

Although I agree that if gramine is unmaintained we should migrate from it in the long term, the fully-fledged KMS alternative you mention does not seem to be in a much better state: This plugin has not yet received an audit. Use at your own risk.

Not sure about how maintained it is (they have very few commits this year for example)

That’s a very good point! I only meant it as an example of a KMS we could use — there might be other projects worth evaluating as well, although I don’t think there are many (if any).

If I had to guess, https://github.com/matter-labs/vault-auth-tee is probably still in better shape than what we’re using now (gramine-sealing-key-provider). AFAIK, zkSync relies on it in production and maintains it internally. Also, AFAIK, it’s built on top of HashiCorp Vault — which is a mature project — and simply wrapped in a TEE. The TEE support was added by Harald Hoyer (@haraldh), and TBH, I trust his code more than what’s in https://github.com/MoeMahhouk/gramine-sealing-key-provider/commits/main/.

You can learn more about the KMS I’m referring to in this presentation, where the author goes into the details: https://youtu.be/2_Duw0z7-nk.

[haraldh]

I am sorry to say that it is unmaintained.. we should make it a real project and talk to IBM... now that they own vault