Hardware-Isolated Policy Engines: Why Fireblocks Runs Its Policy Engine in a TEE

During a tabletop exercise at Upside, we posed this scenario to the engineering team: your CTO’s laptop is compromised. The attacker has the CTO’s credentials, their SSH keys, and their hardware token. What can they do?

In a software-only custody architecture, the answer is alarming. With root-level access to the policy engine server, an attacker can modify the policy in memory, disable the policy checks for a single transaction, or restart the policy engine with a modified binary. The signed policy document stored in your database is irrelevant if the runtime can be bypassed.

This is the fundamental limitation of software-only policy enforcement for high-value custody operations. A software policy engine can be bypassed by anyone who can access the machine running it, because at the machine level, software is just data - and data can be modified.

The hardware-isolated policy engine solves this. It is not a new idea: Fireblocks described the architecture publicly, and it is the reason their value proposition is “your keys are managed by hardware that your own team cannot access.” At ZeroCopy, we implemented the same principle using AWS Nitro Enclaves.

Why Software-Only Policy Engines Are Insufficient

The policy engine in a custody system performs a specific function: given a proposed transaction, determine whether it complies with the defined policy (transaction value limits, destination whitelist, time-delay requirements, required approvals). If compliant, authorize a signing operation. If not compliant, reject it.

In a software-only implementation, the policy engine runs as a process on a Linux server. The process has access to memory, files, and network. An attacker with root access to the server can:

1. Modify the policy engine binary. Replace the policy check function with a stub that always returns “compliant.” The next transaction will be authorized regardless of its contents.

2. Modify the policy in memory. Using a debugger or direct memory write, change the in-memory representation of the policy after it has been loaded but before it is applied to the next transaction.

3. Intercept the authorization signal. The policy engine outputs a signal (“this transaction is authorized”). An attacker between the policy engine and the signing service can modify that signal.

4. Access key material directly. If the signing key is stored on the same server (even encrypted), root access combined with memory inspection can extract it during a signing operation when it is decrypted in memory.

None of these attacks require bypassing the policy logic. They bypass the policy engine entirely.

What a TEE-Based Policy Engine Provides

A Trusted Execution Environment (TEE) is a hardware-isolated execution context. The CPU provides hardware guarantees that code running inside a TEE cannot be observed or modified by software running outside it - including the operating system, the hypervisor, and processes running as root on the host.

The specific guarantees:

Memory isolation. The memory pages used by the TEE are encrypted with keys that only the CPU itself holds. A hypervisor or OS that reads those memory pages sees encrypted data. Even DMA attacks (reading memory directly over PCI buses) cannot extract plaintext from TEE memory.

Code integrity. Before the TEE executes, the CPU measures the code being loaded - it computes a hash over the binary and initial data. This measurement is recorded by the CPU hardware. If the binary is modified, the measurement changes.

Remote attestation. An external verifier can ask the CPU to produce a signed attestation document containing the measurement of the code running in the TEE. The signature uses a key that is burned into the CPU hardware during manufacturing and is trusted by the chip manufacturer (AWS, Intel, AMD). An auditor can verify: “the transaction was processed by code with measurement hash X” - and measurement hash X can be independently computed from the published source code.

No exit path for key material. Key material loaded into a TEE cannot be extracted by the host. The TEE can use the key material internally (for signing) but cannot be coerced into outputting it in plaintext, because no software path exists from inside the TEE to outside except through the defined interfaces.

The Fireblocks Architecture

Fireblocks’ whitepaper describes their custody architecture:

1. MPC-CMP for key management. The private key never exists as a complete value. It is split into shards using Multi-Party Computation - a scheme where the mathematical signing operation can be performed collaboratively by the shard holders without any shard holder ever reconstructing the full key. This means there is no point in time when the complete private key is in memory anywhere.

2. Policy engine in a TEE. Before any signing operation can proceed, the proposed transaction must pass through the TEE-based policy engine. The policy engine runs attested code - its measurement hash is known to auditors and customers. The policy engine checks the transaction against defined rules.

3. Conditional key shard release. The MPC signing operation only proceeds if the policy engine has authorized it. The policy engine’s authorization is a cryptographic proof that the transaction was evaluated by the attested code and found compliant.

The key insight: even if an attacker compromises every host in the Fireblocks infrastructure, they cannot extract the private key (it never exists in plaintext) and they cannot bypass the policy engine (it runs in hardware-isolated code that produces cryptographic proof of what it evaluated).

ZeroCopy’s Nitro Enclave Implementation

AWS Nitro Enclaves are isolated virtual machines with no network access, no persistent storage, and no interactive access. They communicate with the parent EC2 instance through a single vsock channel. The parent cannot inspect or modify the enclave’s memory.

The enclave image is built from source and produces an Enclave Image File (EIF). When the EIF is loaded, the Nitro hypervisor measures it and records the measurement as PCR0 (Platform Configuration Register 0). This measurement is deterministic: the same source code, built with the same toolchain, produces the same PCR0 value.

At ZeroCopy, the policy engine is compiled to an EIF. The PCR0 value is published in our security documentation. Any auditor can:

1. Pull our policy engine source code from the repository
2. Build the EIF using our published toolchain
3. Compare the PCR0 of their built EIF against our published PCR0

If they match, the auditor has independently verified that the policy engine running in production is the code they reviewed. This is the attestation as a compliance artifact.

The KMS key policy that enforces TEE-based access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEnclaveDecrypt",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/enclave-role"
      },
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "StringEqualsIgnoreCase": {
          "kms:RecipientAttestation:PCR0": "0xabc123...the-known-good-measurement"
        }
      }
    },
    {
      "Sid": "DenyAllOthers",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "Null": {
          "kms:RecipientAttestation:PCR0": "true"
        }
      }
    }
  ]
}

The kms:RecipientAttestation:PCR0 condition requires that the decryption request come from an enclave with the specified PCR0 measurement. A request from the host OS (even root), a modified binary, or any other source fails the condition.

The enclave never decrypts the signing key into host memory. The decrypted key material exists only inside the enclave’s memory-isolated execution context.

Policy Rules in the Enclave

The policies implemented in the ZeroCopy policy engine:

// Policy rules evaluated inside the enclave
struct TransactionPolicy {
    max_value_per_transaction: u64,    // Maximum value in base units
    max_value_per_24h: u64,            // Rolling 24-hour value cap
    allowed_destinations: Vec<Address>, // Whitelist
    required_delay_seconds: u64,       // Time-lock for large transactions
    required_approvals: u32,           // Minimum approvals required
}

impl TransactionPolicy {
    fn evaluate(&self, tx: &ProposedTransaction, state: &PolicyState) -> PolicyResult {
        if tx.value > self.max_value_per_transaction {
            return PolicyResult::Rejected("exceeds per-transaction limit".into());
        }

        let rolling_24h = state.sum_value_last_24h + tx.value;
        if rolling_24h > self.max_value_per_24h {
            return PolicyResult::Rejected("exceeds 24h rolling limit".into());
        }

        if !self.allowed_destinations.contains(&tx.destination) {
            return PolicyResult::Rejected("destination not in whitelist".into());
        }

        if tx.approval_count < self.required_approvals {
            return PolicyResult::Rejected("insufficient approvals".into());
        }

        if tx.value > LARGE_TRANSACTION_THRESHOLD {
            let time_since_initiation = state.current_time - tx.initiated_at;
            if time_since_initiation < self.required_delay_seconds {
                return PolicyResult::Delayed {
                    remaining_seconds: self.required_delay_seconds - time_since_initiation,
                };
            }
        }

        PolicyResult::Authorized {
            attestation: self.generate_attestation(tx),
        }
    }
}

The generate_attestation function produces a cryptographic record that includes: the transaction hash, the policy version, the PCR0 measurement of the enclave, and a timestamp. This record is appended to the transaction’s audit trail. An auditor reviewing any historical transaction can see not just that it was authorized, but that it was authorized by the attested policy code with specific measurement hash.

Remote Attestation as a Compliance Artifact

For a SOC 2 audit or a financial regulator review, remote attestation transforms the audit from “trust us that our policy was enforced” to “here is cryptographic proof that every transaction was evaluated by this specific policy code.”

The audit artifact for each transaction:

{
  "transaction_id": "0xabc123...",
  "transaction_hash": "0xdef456...",
  "policy_version": "v2.3.1",
  "enclave_pcr0": "0x7a8b9c...",
  "evaluation_timestamp": "2026-03-29T14:22:31.441Z",
  "policy_result": "AUTHORIZED",
  "attestation_signature": "0x112233...",
  "attestation_document_hash": "0xaabbcc..."
}

The auditor can verify:

1. The enclave_pcr0 matches the published measurement for the claimed policy_version
2. The attestation_signature is valid under the AWS Nitro attestation root of trust
3. The attestation_document_hash matches a document in the Rekor transparency log

This chain of verification means the attestation is not just a claim - it is a proof that anyone with the public verification key can independently check.

Comparing TEE Platforms: Nitro vs SGX vs TrustZone

Several TEE platforms are in production use for custody applications. The tradeoffs matter for architecture decisions.

AWS Nitro Enclaves are the choice ZeroCopy made. The architecture is clean: the enclave is a separate VM with no network interface, no persistent storage, and a single vsock channel to the parent EC2 instance. The PCR measurements cover the full enclave image - any modification to the code changes PCR0. The KMS integration is first-class: KMS key policies can specify PCR conditions directly, without additional infrastructure.

The limitation: Nitro Enclaves require EC2. If you are running on a different cloud provider or on-premises hardware, Nitro is not available.

Intel SGX (Software Guard Extensions) provides TEE capabilities at the CPU instruction level, available on many Intel processors. SGX enclaves can run on any hardware with a supported Intel CPU, including on-premises and co-located hardware. The attestation mechanism is Intel’s Data Center Attestation Primitives (DCAP) service.

The complexity: SGX development is more involved than Nitro. The enclave code must be written to use SGX-specific APIs. Memory is limited (the EPC, Enclave Page Cache, is constrained hardware memory). Attestation requires running the DCAP infrastructure.

ARM TrustZone is the TEE for mobile and embedded devices. Less relevant for server-side trading infrastructure, but relevant for signing hardware wallets and mobile approval apps in a custody system.

For a new deployment choosing a TEE platform: if your trading infrastructure is on AWS EC2, Nitro Enclaves are the clear choice for their operational simplicity and native KMS integration. If you need hardware-independent portability or are on-premises, SGX provides equivalent security guarantees with additional operational overhead.

The Audit Trail from Transaction to Attestation

One of the most underappreciated properties of a TEE-based policy engine is the unbroken audit trail it creates. For a transaction to be authorized, the following chain must hold:

1. The transaction was submitted through an authorized channel (verifiable from access logs)
2. The transaction was received by the policy engine enclave (verifiable from the enclave’s vsock input log)
3. The policy engine evaluated the transaction against the declared policy (verifiable from the policy engine’s deterministic logic)
4. The policy engine produced an authorization attestation (verifiable by checking the attestation signature against the Nitro root of trust)
5. The signing service verified the attestation before proceeding (verifiable from the signing service logs)
6. The signing service used the key material to produce a signature (verifiable from the blockchain transaction record)

Each link in this chain is independently verifiable by a third party. An auditor who wants to verify that transaction 0xabc123 was authorized by a compliant policy can follow this chain from the blockchain transaction back to the original authorization request, with cryptographic proof at every step.

This is a qualitatively different level of auditability than a software-only system, where the audit trail consists of log files that could in principle be modified by an administrator with access to the logging infrastructure.

How This Breaks in Production

The failure mode I see in TEE-based policy implementations is not a TEE bypass - breaking the hardware isolation is essentially impossible with current technology. The failure mode is in the policy update process.

When you need to update the policy (add a new allowed destination, increase a transaction limit), you need to rebuild the enclave image, compute the new PCR0, update the KMS key policy, and deploy the new enclave. If this process is complex, engineers will create shortcuts - a “policy override” endpoint that does not go through the enclave, or a debugging mode that disables the attestation check.

The fix: the policy update process must be as secure as the policy itself. At ZeroCopy, policy updates go through the same change management process as production code changes - dual review, signed attestation of the update, audit trail. The KMS key policy is never updated without a corresponding git commit that records the new PCR0 value and the justification for the policy change.

The second failure mode is key recovery. If the enclave is unavailable (hardware failure, instance termination), the key material wrapped for that enclave’s PCR0 cannot be decrypted. You need a recovery procedure that does not bypass the policy controls - typically a second enclave with a different PCR0 that has been granted recovery access under strict conditions.

Design the recovery path before you need it. Key recovery under time pressure, with unavailable infrastructure, is when security corners get cut.

The third failure mode is treating the attestation document as an internal artifact rather than a customer-facing proof. The power of remote attestation is that anyone with the Nitro root of trust public key - which is published by AWS - can independently verify that your transaction was authorized by the attested code. If you keep attestation documents internal, you lose the primary differentiating value: the ability to prove your controls to auditors, customers, and regulators without requiring them to trust your word.

Publish your PCR0 values. Document the verification procedure. Give auditors the tools to verify the chain themselves. That transparency, grounded in cryptographic proof, is what separates a custodian that can prove its security posture from one that merely claims it.

Economic Incentives and the TEE Adoption Gap

Given the clear security advantages, why is TEE-based custody still not the norm? The adoption gap has three drivers.

Development complexity. Writing code that runs correctly inside a Nitro Enclave requires understanding memory constraints (the enclave has no swap), communication restrictions (vsock only), and the attestation lifecycle. Teams that have not worked with TEEs before typically require 4-8 weeks of engineering time to produce a production-ready enclave. For a startup under capital pressure, this investment is hard to justify.

Operational overhead. Managing enclave deployments - the build pipeline that produces attested EIFs, the PCR0 publication process, the KMS key policy updates for policy changes - is more complex than managing standard containerized workloads. Teams that have not built a run-book for this tend to create operational debt that bites them during incident response.

The security theater alternative. A firm can claim to use “hardware-based custody” by buying an HSM to store keys and managing everything else in software. The HSM prevents direct key extraction but does not address the policy engine bypass threat. This is cheaper to implement and easier to explain, and it satisfies most buyers who are not asking the right questions.

The firms that make the investment - Fireblocks, ZeroCopy, and a growing number of institutional custodians - do so because the customers who are most valuable to them (institutional asset managers, regulated funds) are starting to ask the right questions. “Can you prove your policy was enforced for this transaction?” The answer that satisfies is an attestation document, not a policy document.