> ## Documentation Index
> Fetch the complete documentation index at: https://fhenix-docs-deep-dive-rewrite.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Key Management

> How CoFHE's keys are created in an attested ceremony, split among independent partners, and released only to attested enclaves

CoFHE's security rests on a small set of keys, and none of them is ever held whole by any person or machine outside an attested enclave.

| Key                  | Used by                                                | Purpose                                                     |
| -------------------- | ------------------------------------------------------ | ----------------------------------------------------------- |
| FHE network key      | [Teecryptor](/deep-dive/cofhe-components/teecryptor)   | Decrypts ciphertexts inside the enclave                     |
| Result-signing key   | Teecryptor                                             | Signs decrypt results the TaskManager verifies onchain      |
| Verifier signing key | [ZK Verifier](/deep-dive/cofhe-components/zk-verifier) | Signs verified input batches                                |
| Public material      | Everyone                                               | The network public key and CRS that clients encrypt against |

## The ceremony

The keys are born inside a TEE. A one-shot key-generation service runs in its own hardware-attested enclave and generates the network keyset there. The secret material is split with Shamir secret sharing into six shares; any three reconstruct it (3-of-6).

Each share goes to one **partner**: an independent custodian with its own share store. A partner's store accepts writes only from the attested ceremony image, so nobody can slip in a substitute share. The public material is published for clients. The ceremony enclave then terminates; the assembled key is never persisted anywhere.

```mermaid theme={null}
%%{init: {"theme": "base", "themeVariables": {"fontFamily": "Menlo, Monaco, Consolas, monospace", "fontSize": "16px", "primaryColor": "#8FBAF5", "primaryBorderColor": "#2E7CF6", "primaryTextColor": "#0A1626", "lineColor": "#4C8DFF", "signalColor": "#4C8DFF", "signalTextColor": "#8FA3BF", "actorBkg": "#8FBAF5", "actorBorder": "#2E7CF6", "actorTextColor": "#0A1626", "actorLineColor": "#3D4654", "noteBkgColor": "#14171C", "noteBorderColor": "#3D4654", "noteTextColor": "#AFC3DE", "activationBkgColor": "#1E3A5F", "activationBorderColor": "#4C8DFF", "clusterBkg": "#14171C", "clusterBorder": "#3D4654", "titleColor": "#E7EAEE", "edgeLabelBackground": "#8FBAF5", "textColor": "#AFC3DE", "labelTextColor": "#E7EAEE", "tertiaryColor": "#14171C", "loopTextColor": "#AFC3DE", "labelBoxBkgColor": "#1E3A5F", "labelBoxBorderColor": "#4C8DFF"}, "sequence": {"actorFontFamily": "Menlo, Monaco, Consolas, monospace", "messageFontFamily": "Menlo, Monaco, Consolas, monospace", "noteFontFamily": "Menlo, Monaco, Consolas, monospace", "width": 220, "actorFontSize": 16, "messageFontSize": 16, "noteFontSize": 15}}}%%
sequenceDiagram
    participant Ceremony as Keygen ceremony (TEE)
    participant Partners as Partners (custodians)
    participant Pub as Public material
    participant Enclave as Service enclave

    Note over Ceremony: generates the keyset in-enclave,<br/>splits secrets with Shamir (3-of-6)
    Ceremony->>Partners: one encrypted share per partner (attested write)
    Ceremony->>Pub: publish public material
    Note over Ceremony: terminates, whole key<br/>never persisted
    Note over Partners,Enclave: later, at every service boot
    Enclave->>Partners: attestation of the running image
    Note over Partners: each partner verifies independently
    Partners-->>Enclave: release share, only to the approved image
    Note over Enclave: reconstruct in memory,<br/>zeroize transit material
```

## Custody

At rest, the key exists only as shares held by independent partners. No partner can reconstruct anything alone, and no quorum below the threshold can either. Fhenix operates the services, but it cannot assemble the key outside an attested enclave any more than anyone else can.

## Release at boot

When Teecryptor or the ZK Verifier starts, the TEE hardware produces an attestation of the exact code image it is running. Each partner independently verifies that attestation and releases its share only to the approved image digest. The enclave reconstructs the key in memory, zeroizes the transit material, and never persists it. Restarting the service repeats the whole handshake.

The guarantee this chain yields: from generation through every reconstruction, the key exists only inside hardware-attested enclaves running reviewed code.