Security

Fortkey is designed around one principle: maximum security with zero trust in human access. Private keys are generated, encrypted, and used without ever being exposed to any person or system outside the secure enclave, including Fortkey itself.

Two guarantees follow:

• No Fortkey employee or system ever has access to a raw private key, apart from the enclave.
• Only the client can authorize the decryption and use of a private key. Fortkey cannot.

Conceptual signing flow

Every signature goes through five steps:

1. User authorization and policy checks. After authentication, the policy engine verifies the user's role (RBAC), confirms wallet access, and evaluates the decoded transaction payload against all active trading policies.
2. Key retrieval. The encrypted private key is loaded from the database into the enclave. It is protected by multiple layers of KMS encryption (two by default; configurable).
3. Initial decryption. The first KMS encryption layer is removed inside the enclave.
4. Full decryption. Remaining layers are removed, yielding the raw key only inside the enclave.
5. Transaction signing. The signature is produced inside the isolated Trusted Execution Environment. The raw key never leaves it.

Security components

Trusted Execution Environment: AWS Nitro Enclaves

Nitro Enclaves are isolated compartments carved out of an EC2 instance's CPU and memory. No process on the host instance can read enclave memory. Enclaves have no internet access; they communicate only with their parent instance over a VSOCK channel. Fortkey layers mutual TLS on top of that channel, so not even an arbitrary process on the host can command the enclave.

Enclave attestation and KMS integration

The AWS Nitro hypervisor measures the enclave (kernel, application code, filesystem: think of a measurement as a hash) and cryptographically signs those measurements. This attestation document authenticates the enclave to the outside world. AWS KMS key policies can require a valid attestation with expected measurements (PCR values), so only the genuine, unmodified enclave can decrypt key material. The right code, and nothing else, gets access.

Layered KMS encryption

A single KMS key policy is a single point of attack: a compromised administrator could loosen it. Fortkey therefore layers encryption with multiple KMS keys, each governed by a different administrator. Compromising the scheme requires taking over the key policies of every layer at once. Two layers are default; clients can add more, entirely under their own control, and a fully on-premises deployment is available where all KMS encryption is customer-managed. Key policies are continuously monitored (CloudTrail, AWS Config) so any tampering is spotted quickly.

Mutual TLS everywhere

All internal and external communication uses mTLS: strong service authentication, encryption in transit, and client-specific certificates that reduce impersonation risk.

Roles, access policies, trading policies

Cryptography protects keys; controls protect usage. Roles govern what a user can do on the platform, access policies govern which wallets they can touch, and trading policies govern what transactions can be signed. See policy-engine.md.

Private key lifecycle

The flow involves three components: the client's KMS (KMS1), the enclave, and Fortkey's KMS (KMS2, optional but recommended).

Key generation

1. Generation inside the enclave. On client request, the enclave generates a new private key X. It is never visible outside the enclave.
2. Client-side encryption first. The enclave has KMS1 encrypt the key, producing E1(X). The inner encryption layer always belongs to the client, so even someone with database access could never retrieve a usable key. Transit is protected by mTLS.
3. Fortkey encryption second. KMS2 encrypts again, producing E2(E1(X)). A compromise of the client environment alone can no longer expose the key; Fortkey would have to be breached as well. Additional layers can be added on either side.
4. Provenance signature. KMS policies verify enclave measurements only on decryption, not on encryption. To prove the stored key genuinely originated in a trusted enclave (and was not maliciously inserted into the database), the enclave requests a one-time data key Y from KMS1, uses it to sign E2(E1(X)), then discards Y. The encrypted key, the signature, and the encrypted data key E1(Y) are stored together. The step repeats per KMS involved.

Key decryption (signing time)

1. Attested data key release. On a signing request, the enclave sends E1(Y) to KMS1. KMS1 checks the enclave's PCR values against its key policy; only a trusted Fortkey enclave gets Y back.
2. Signature verification. The enclave verifies the stored provenance signature with Y, proving the key was generated inside a trusted enclave. Repeated per layer.
3. Layered decryption. KMS2 validates attestation and strips the outer layer, returning E1(X); KMS1 validates attestation and strips the inner layer, yielding the raw key X inside the enclave only.
4. Signing. The enclave signs the transaction and the raw key never leaves it.

What this means for a security review

• Database compromise yields only multiply-encrypted key material, unusable without both KMS authorities and a genuinely attested enclave.
• Fortkey insider compromise cannot decrypt keys: the inner layer is the client's.
• Client credential compromise alone cannot decrypt keys either: the outer layer and enclave attestation still gate usage.
• Every signature is preceded by policy evaluation inside the trust boundary; there is no code path to a signature that skips the policy engine.