Skip to main content

Security and Trust Model

Trust Requirements

EigenCompute currently requires trust in:

Security Boundaries

  • Trust boundary: You trust the TEE hardware manufacturer, Google Confidential Space attestation service, KMS attestation process
  • Your responsibility: Application logic, dependency security, and secret handling within your code.
  • Platform/EigenLabs responsibility: Infrastructure security, TEE provisioning, and KMS operation.
Security Enhancements in Development

Security enhancements in development:

  • Public attestation endpoints for runtime verification
  • Threshold KMS for distributed key management
  • Replica prevention via onchain checks and heartbeats
  • Verifiably built images with reproducible builds

Threat Model

The EigenCompute TEE/KMS architecture protects against:

Attack VectorProtection
Malicious cloud providersEigenLabs cannot access your TEE memory or runtime data. In the Mainnet Alpha phase, EigenLabs has access to KMS keys and can theoretically decrypt environment variables. Future releases will eliminate this access through an external hardened KMS system.
Infrastructure compromiseEven if host machines are compromised, TEE hardware isolation prevents secret extraction.
Man-in-the-middle attacksEncrypted secrets can only be decrypted inside TEE instances verified using attestation.
Secret exfiltration by OperatorsKMS cryptographically binds secrets to your specific TEE. In the Mainnet Alpha phase, EigenLabs has access to KMS keys and can theoretically decrypt environment variables. Future releases will eliminate this access through an external hardened KMS system.
Credential theft from storageSecrets are stored encrypted onchain and in the KMS. Secrets are never stored in plaintext outside your TEE.
Supply chain attacks on infrastructureAttestation ensures only genuine TEE hardware with verified measurements can decrypt secrets.

The EigenCompute TEE/KMS architecture does not protect against:

Attack VectorMitigation
Vulnerable application codeReview and test your code for traditional vulnerabilities (for example, injection attacks, XSS).
Secrets logged by your appImplement proper logging hygiene. Never log sensitive values.
Compromised dependenciesAudit your dependencies and use trusted sources for packages.
Side-channel attacksWhile TEEs mitigate many side-channels, be cautious with timing-sensitive operations.
Physical access attacksTEE protects against remote attacks, but sophisticated physical access could theoretically compromise hardware.
Malicious container imagesYou control your container. Ensure you build from trusted base images and scan for vulnerabilities.