MPC, HSM, and TEE Explained: A Developer’s Guide to Key Management Technologies in Wallet Infrastructure

The cryptographic foundations that secure billions in crypto assets — how they work, their tradeoffs, and which to choose for your use case

When you create a wallet through a WaaS provider, something remarkable happens in milliseconds: cryptographic operations that took decades of research to develop execute seamlessly, protecting potentially millions in assets.

But what actually happens? How are keys generated, stored, and used for signing without ever being fully exposed?

Three technologies dominate modern key management: Multi-Party Computation (MPC), Hardware Security Modules (HSM), and Trusted Execution Environments (TEE). Each takes a fundamentally different approach to the same problem: how do you use a private key without exposing it to theft?

After years implementing wallet infrastructure and evaluating these technologies, I’ve developed a deep appreciation for both their elegance and their limitations. This guide breaks down each technology, explains how they work, and helps you understand which is right for your use case.

SECTION 1: THE KEY MANAGEMENT PROBLEM

1.1 Why Key Management Is Hard

Private keys have a fundamental tension:

• To be useful: The key must be accessible for signing transactions
• To be secure: The key must never be exposed to potential attackers

Traditional approaches fail this tension:

Plain Storage (Encrypted Database)

During signing, the full key exists in memory. Any memory dump, side-channel attack, or compromised process can extract it.

The Goal: Sign transactions without the complete key ever existing in one place.

1.2 The Key Management Trilemma

Every solution trades off between:

1. Security: Protection against key theft
2. Availability: Ability to sign when needed
3. Recoverability: Ability to restore access if something fails

No technology optimizes all three. Understanding the tradeoffs is essential.

SECTION 2: MULTI-PARTY COMPUTATION (MPC)

2.1 The Core Idea

MPC allows multiple parties to jointly compute a function over their inputs without revealing those inputs to each other.

For key management: Multiple parties each hold a “share” of the private key. They can collectively sign transactions without any party ever learning the complete key.

2.2 How MPC Signing Works

Simplified 2-of-2 threshold signature:

2.3 Threshold Signatures Explained

MPC enables “t-of-n” threshold schemes:

• 2-of-3: Any 2 of 3 share holders can sign (most common)
• 3-of-5: Any 3 of 5 share holders can sign
• m-of-n: General threshold scheme

// Conceptual MPC key generation
interface MPCKeyShares {
  threshold: number;      // Minimum shares needed (t)
  totalShares: number;    // Total shares created (n)
  shares: KeyShare[];     // Individual shares
  publicKey: string;      // Combined public key (safe to share)
}

class MPCKeyManager {
  async generateShares(t: number, n: number): Promise<MPCKeyShares> {
    // Generate random polynomial of degree t-1
    // Secret is the constant term (never revealed)
    const polynomial = this.generatePolynomial(t - 1);

    // Evaluate polynomial at n points to create shares
    const shares: KeyShare[] = [];
    for (let i = 1; i <= n; i++) {
      shares.push({
        index: i,
        value: this.evaluatePolynomial(polynomial, i),
      });
    }

    // Derive public key from secret (without exposing secret)
    const publicKey = this.derivePublicKey(polynomial.secret);

    return {
      threshold: t,
      totalShares: n,
      shares,
      publicKey,
    };
  }
}

2.4 MPC Protocols in Practice

Two main approaches:

GG18/GG20 (Gennaro-Goldfeder)

• Most widely deployed
• 6–8 rounds of communication
• Well-audited, battle-tested
• Used by: Fireblocks, many others

CGGMP (Canetti-Gennaro-Goldfeder-Makriyannis-Peled)

• Newer, improved protocol
• Fewer rounds (faster)
• Better security proofs
• Becoming the new standard

// Simplified MPC signing flow
class MPCSigner {
  async sign(
    message: Buffer,
    shares: KeyShare[],
    threshold: number
  ): Promise<Signature> {

    // Verify we have enough shares
    if (shares.length < threshold) {
      throw new Error(`Need ${threshold} shares, have ${shares.length}`);
    }

    // Phase 1: Generate signing nonces
    const nonces = await this.generateNonces(shares);

    // Phase 2: Compute partial signatures
    const partials = await Promise.all(
      shares.map((share, i) => 
        this.computePartialSignature(message, share, nonces[i])
      )
    );

    // Phase 3: Combine partial signatures
    const signature = this.combinePartials(partials);

    // Verify before returning
    if (!this.verifySignature(message, signature)) {
      throw new SignatureError('Generated signature is invalid');
    }

    return signature;
  }
}

2.5 MPC Key Rotation

A killer feature of MPC: rotate key shares without changing the public key/address.

This is impossible with traditional key management.

2.6 MPC Advantages

✅ No single point of compromise: Key never exists in one place

✅ Flexible policies: Different thresholds for different operations

✅ Key rotation: Refresh shares without changing address

✅ Geographic distribution: Shares in different data centers/jurisdictions

✅ Auditability: Clear access logs for each share holder

2.7 MPC Disadvantages

❌ Latency: Multiple rounds of communication required

❌ Complexity: Sophisticated cryptography, hard to implement correctly

❌ Coordination: Share holders must be online simultaneously

❌ Recovery complexity: Lost shares require backup mechanisms

❌ Protocol vulnerabilities: Bugs in MPC protocols have been found

SECTION 3: HARDWARE SECURITY MODULES (HSM)

3.1 The Core Idea

HSMs are specialized hardware devices designed for cryptographic operations. Keys are generated inside the HSM and never leave it — signing happens within the tamper-resistant hardware.

3.2 HSM Security Features

Physical Security:

• Tamper-evident seals
• Tamper-responsive circuitry (zeroize keys if breached)
• Environmental sensors (temperature, voltage)
• Secure enclosure

Logical Security:

• Role-based access control
• Multi-person authentication (M-of-N operator cards)
• Comprehensive audit logging
• Secure key generation with certified entropy

3.3 HSM Certifications

3.4 Cloud HSM Options

// AWS CloudHSM integration example
import { CloudHSMClient, SignCommand } from '@aws-sdk/client-cloudhsm';

class AWSHSMSigner {
  private client: CloudHSMClient;
  private keyHandle: string;

  async sign(message: Buffer): Promise<Buffer> {
    const hash = crypto.createHash('sha256').update(message).digest();

    const command = new SignCommand({
      KeyHandle: this.keyHandle,
      Message: hash,
      SigningAlgorithm: 'ECDSA_SHA_256',
    });

    const response = await this.client.send(command);
    return Buffer.from(response.Signature);
  }
}

Cloud HSM Providers:

3.5 HSM Advantages

✅ Highest security certification: FIPS 140–2/3, Common Criteria

✅ Tamper resistance: Physical protection against extraction

✅ Audit compliance: Meets regulatory requirements

✅ High performance: Hardware-accelerated crypto operations

✅ Proven track record: Decades of use in banking, government

3.6 HSM Disadvantages

❌ High cost: $50K-$200K+ for physical HSM; $1–5K/month for cloud

❌ Single point of failure: If HSM fails, keys are inaccessible

❌ Geographic limitations: Physical HSM tied to location

❌ Vendor lock-in: Key extraction often impossible

❌ Scaling challenges: Adding capacity means adding hardware

❌ Limited flexibility: Fixed authentication policies

SECTION 4: TRUSTED EXECUTION ENVIRONMENTS (TEE)

4.1 The Core Idea

TEEs create isolated processing environments within a CPU where code and data are protected from the rest of the system — including the operating system and hypervisor.

4.2 TEE Technologies

Intel SGX (Software Guard Extensions)

• Most mature TEE for servers
• Enclaves up to ~256MB
• Remote attestation supported
• Past vulnerabilities (Spectre, Foreshadow, etc.)

ARM TrustZone

• Dominant in mobile devices
• Used in smartphone secure elements
• Hardware-level world separation

AMD SEV (Secure Encrypted Virtualization)

• VM-level isolation
• Memory encryption per VM
• Good for confidential computing

AWS Nitro Enclaves

• Amazon’s isolated compute
• No persistent storage
• No external networking from enclave
• Used for sensitive workloads

4.3 TEE Attestation

Attestation proves that code running in the enclave is legitimate:

// Simplified TEE attestation flow
class TEEAttestationVerifier {
  async verifyEnclave(attestationReport: AttestationReport): Promise<boolean> {
    // 1. Verify the report signature (from CPU)
    const signatureValid = await this.verifyIntelSignature(
      attestationReport.signature,
      attestationReport.body
    );

    if (!signatureValid) return false;

    // 2. Check enclave measurement (code hash)
    const expectedMeasurement = this.getExpectedMeasurement();
    if (attestationReport.mrenclave !== expectedMeasurement) {
      return false;
    }

    // 3. Verify enclave is running on genuine Intel CPU
    const cpuVerified = await this.verifyWithIntelAttestationService(
      attestationReport
    );

    return cpuVerified;
  }
}

4.4 TEE in Production: Turnkey’s Approach

Turnkey (a popular WaaS provider) uses TEE extensively:

4.5 TEE Advantages

✅ Lower cost than HSM: Uses standard CPUs with TEE support

✅ Scalable: Add more instances easily in cloud

✅ Attestation: Cryptographic proof of code integrity

✅ Cloud-native: Available in AWS, Azure, GCP

✅ Non-custodial friendly: Provider can prove they can’t access keys

4.6 TEE Disadvantages

❌ Historical vulnerabilities: SGX has had multiple attacks (Spectre variants, Plundervolt, etc.)

❌ Trust in hardware vendor: Must trust Intel/AMD/ARM

❌ Limited memory: SGX enclaves have size constraints

❌ Side-channel risks: Timing attacks, cache attacks

❌ Attestation complexity: Proper verification is non-trivial

SECTION 5: COMPARING THE THREE APPROACHES

5.1 Security Comparison

5.2 Operational Comparison

5.3 Use Case Recommendations

Choose MPC if:

• You need distributed trust (no single point of compromise)
• Geographic distribution is important
• Key rotation without address change is valuable
• You’re building non-custodial or hybrid custody
• You have the engineering expertise to implement correctly

Choose HSM if:

• Regulatory compliance requires FIPS certification
• You’re in regulated finance (banking, securities)
• Maximum security certification is required
• Performance is critical (high-frequency signing)
• You have budget for hardware costs

Choose TEE if:

• Cost-efficiency is important
• You need cloud-native scalability
• Non-custodial proof is important (attestation)
• You’re comfortable with known/mitigated risks
• You want provider flexibility

5.4 Hybrid Approaches

Many production systems combine approaches:

MPC + HSM:

Key shares stored in HSMs for additional protection

Share A in HSM A + Share B in HSM B → Combined MPC signing

MPC + TEE:

MPC protocol runs inside TEE for additional isolation

Share A in TEE A + Share B in TEE B → Double protection

SECTION 6: IMPLEMENTATION CONSIDERATIONS

6.1 Key Ceremony Best Practices

Initial key generation is critical:

// Key ceremony checklist
interface KeyCeremonyRequirements {
  // Environment
  airGappedEnvironment: boolean;     // No network during generation
  multipleWitnesses: number;          // At least 2 witnesses
  videoRecording: boolean;            // Document the process

  // Process
  entropyVerification: boolean;       // Verify randomness quality
  shareDistribution: 'in-person' | 'secure-channel';
  backupCreation: boolean;            // Create recovery backups

  // Verification
  testSigning: boolean;               // Verify shares work together
  documentationComplete: boolean;     // Record all steps
}

6.2 Backup and Recovery

Every key management approach needs a recovery strategy:

MPC Recovery:

• Store encrypted share backups
• Use Shamir’s Secret Sharing for backup shares
• Geographically distribute backups
• Test recovery process regularly

HSM Recovery:

• HSM backup cards (m-of-n operator cards)
• Secure offsite storage
• Documented recovery procedures
• Regular recovery drills

TEE Recovery:

• Encrypted key backups outside TEE
• Secondary TEE instances
• Key derivation from master seed

6.3 Monitoring and Alerting

// Key management monitoring points
interface KeyManagementMonitoring {
  // Health checks
  shareHolderAvailability: 'all-online' | 'degraded' | 'critical';
  hsmStatus: 'healthy' | 'warning' | 'error';
  teeAttestationStatus: 'valid' | 'expired' | 'failed';

  // Security alerts
  unusualSigningPatterns: boolean;
  failedAuthenticationAttempts: number;
  accessFromUnknownIPs: boolean;

  // Operational metrics
  signingLatencyP99: number;
  signingSuccessRate: number;
  queueDepth: number;
}

CONCLUSION

Key management technology choice is one of the most consequential decisions in wallet infrastructure. Each approach — MPC, HSM, and TEE — offers genuine advantages and real limitations.

The right choice depends on:

1. Regulatory requirements: HSM for FIPS compliance
2. Trust model: MPC for distributed trust
3. Cost constraints: TEE for cost efficiency
4. Scaling needs: MPC or TEE for cloud-native
5. Risk tolerance: HSM for maximum security track record

For most modern WaaS applications, MPC has become the default choice due to its unique combination of distributed trust and operational flexibility. But the best implementations often combine multiple approaches for defense in depth.

Building or evaluating wallet infrastructure? Understanding these technologies is essential for making the right choice.

DM me if you’re navigating key management decisions — I’ve implemented all three approaches and can help you think through the tradeoffs.