> ## Documentation Index
> Fetch the complete documentation index at: https://fhenix-docs-broken-sample-fixes.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 read back by Teecryptor and the ZK Verifier at boot

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 keygen ceremony 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.

<Frame>
  <img src="https://mintcdn.com/fhenix-docs-broken-sample-fixes/R2TEFe1LBG2Y-SXN/images/key-management.svg?fit=max&auto=format&n=R2TEFe1LBG2Y-SXN&q=85&s=343f73dd7f4032578001a62a9fa97b6d" alt="Sequence diagram of the key management" width="1440" height="730" data-path="images/key-management.svg" />
</Frame>

<Tip>
  Color marks the zone. The keygen ceremony and the component enclave (Teecryptor or the ZK Verifier) run inside CoFHE. The partners are independent custodians, so they are not colored as CoFHE's. Hover any component or message in the [explorable version](/deep-dive/cofhe-components/key-management-explorable).
</Tip>

## 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 components, but it cannot assemble the key outside an attested enclave any more than anyone else can.

## Who reads the shares

Two components read key material, and each reads only its own. Teecryptor reads the share carrying the FHE key and the result-signing key. The ZK Verifier reads the share carrying its own signing key. Neither can read the other's, and that separation is enforced by access control on each partner's store, not by trusting the code to behave.

## Release at boot

The reading is done by `cofhe-keys`, a library compiled into the component itself. It is part of the image the partners approve, so the code that reconstructs a key is the same code the attestation covers.

<Steps>
  <Step title="The component attests">
    When Teecryptor or the ZK Verifier starts, the TEE hardware produces an attestation of the exact code image it is running.
  </Step>

  <Step title="Each partner decides on its own">
    Every partner independently verifies that attestation and releases its share only to the approved image digest. No partner takes another's word for it.
  </Step>

  <Step title="cofhe-keys reconstructs">
    It gathers shares from every partner it can reach, so one unreachable partner does not stop a boot. It checks each share against its own digest and discards any that fails, then reconstructs from the threshold and validates the result against the published digest. A share that does not verify is dropped rather than used.
  </Step>

  <Step title="The key stays in memory">
    The component zeroizes the transit material and never persists the assembled key. Restarting it repeats the whole handshake.
  </Step>
</Steps>

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