The Conventional Wisdom
You've heard the pitch: distribute your signing keys across multiple parties using threshold signatures, then run those shares inside Trusted Execution Environments (TEEs). The TEE isolates cryptographic operations from compromised hypervisors, malicious sysadmins, and vulnerable application stacks. Single-point key compromise becomes theoretically impossible.
Security teams are buying this story. They're deploying threshold ECDSA and FROST protocols inside AMD SEV-SNP and Intel TDX confidential VMs, believing the hardware enclave provides a security boundary that traditional software protections can't match. The logic seems sound: if the key share never touches untrusted memory, how can it leak?
Why We Disagree
TEEs don't eliminate your threat surface. They relocate it.
When you run threshold signatures inside confidential VMs, you're trading one set of attack vectors for another. Yes, the hypervisor can't read your key material during signing operations. But you've introduced new dependencies: the TEE vendor's attestation chain, the firmware update process, the enclave's persistent state management, and the Byzantine fault assumptions in your threshold protocol.
Recent research shows that while the performance overhead is manageable, the security model remains incomplete. DKG completes within seconds for 40 participants in evaluated configurations. Signing operations finish in tens of milliseconds. Threshold BLS runs approximately twice as slow as FROST for comparable values of n and t. These numbers look good on paper.
What the benchmarks don't measure: attestation-bound provisioning lifecycle coverage, persistent-state rollback protection, or Byzantine fault behavior under active attack.
The Evidence
Your TEE-based threshold signature deployment has three unresolved problems:
First, attestation complexity. Before your signing service can trust a key share from another participant's TEE, it must verify a chain of measurements from the CPU's root of trust through the firmware, bootloader, and enclave code. This attestation chain has failed before. When a vendor patches a side-channel vulnerability in the TEE implementation, every participant must re-attest. Your signing service becomes unavailable until all parties upgrade and re-establish trust. You've converted a cryptographic protocol into an operational dependency on vendor security response timelines.
Second, state rollback vulnerabilities. Threshold protocols maintain session state: nonces in FROST, ephemeral secrets in GG20 threshold ECDSA. If an attacker can revert your TEE to a previous state snapshot and replay a signing request, they can extract key material through nonce reuse. Cloud-based confidential VMs typically lack hardware-enforced monotonic counters that would prevent this attack. You're trusting the cloud provider's snapshot isolation policies, which contradicts the threat model that motivated your TEE deployment in the first place.
Third, Byzantine participant assumptions. Threshold signatures tolerate t-1 compromised parties in an n-participant protocol. But when you run those parties inside TEEs on infrastructure you don't control, what does "compromised" mean? A malicious cloud provider can't read your key share, but they can delay your signing messages, corrupt your network connections to other participants, or simply power off your CVM during the protocol's critical phases. Your threshold protocol's liveness guarantees evaporate when the infrastructure itself becomes adversarial.
What to Do Instead
Treat TEEs as defense-in-depth, not as your primary security boundary.
Start with protocol-level protections. Choose threshold schemes with proven security reductions that don't rely on hardware assumptions. FROST and threshold BLS both offer stronger theoretical guarantees than GG20 threshold ECDSA for your use case. Document which attacks your threshold protocol prevents (key exfiltration through malware) versus which attacks it cannot prevent (coerced signing by a legitimate participant).
Layer your attestation verification. Don't just verify the TEE's initial boot measurement. Implement continuous attestation: before each signing operation, participants should re-verify each other's enclave state. This won't prevent all rollback attacks, but it raises the bar for persistent compromise. Use NIST SP 800-63B identity proofing requirements as a model: verify the binding between the cryptographic identity and the operational entity at multiple points in the protocol lifecycle.
Build operational resilience into your participant set. If you're running threshold signatures across cloud confidential VMs, distribute those VMs across different cloud providers and different geographic regions. The goal isn't just fault tolerance; it's to ensure that no single infrastructure operator can halt your signing service through VM manipulation. This addresses the Byzantine fault scenarios that current TEE evaluations don't cover.
Monitor for enclave degradation. Your signing service should track per-participant latency, attestation failures, and protocol timeouts. When one participant's TEE starts showing anomalous behavior (slower signing, frequent re-attestation requests, dropped messages), that's your signal to rotate that key share out of the active set. Don't wait for a confirmed breach.
When the Conventional Wisdom Is Right
TEEs do solve one specific problem well: they protect key material from exfiltration by privileged software on the same physical host.
If your threat model includes malicious sysadmins, compromised hypervisors, or memory-scraping malware in the payment application's address space, confidential VMs provide meaningful protection. The overhead is reasonable: tens of milliseconds for signing operations won't break your authorization flow. For payment processors handling high-value transactions where the cost of a single key compromise exceeds the operational complexity of TEE deployment, the tradeoff makes sense.
The conventional wisdom also holds when you're already operating in a cloud environment and can't control the physical infrastructure. Running threshold signatures in plaintext VMs on that same infrastructure gives you zero protection against the cloud provider. Running them in confidential VMs at least forces the provider to execute more sophisticated attacks (firmware compromise, side-channel exploitation) rather than simple memory inspection.
But don't confuse "better than plaintext" with "sufficient." Your TEE-based threshold signature deployment needs the same operational discipline you'd apply to any cryptographic key management system: rotation schedules, compromise detection, incident response procedures, and regular security reviews. The hardware enclave doesn't eliminate those requirements. It just changes which controls matter most.
