Security
How Sigcore protects keys.
The homepage explains what we guarantee. This page explains how: the hardware we rely on, the cryptography around it, and the exact flow of every request. Written for security teams and the engineers who have to sign off.
Architecture
Zero-access by design. Verifiable by default.
This page is for security teams and engineers who want the full picture: which hardware we rely on, what runs inside it, and how you can check our claims yourself.
Trusted execution environments
AMD SEV-SNP confidential computing.
All signing operations execute inside AMD SEV-SNP Secure Encrypted Virtualization enclaves. Memory is hardware-encrypted with a per-VM key that the hypervisor, host OS and cloud provider cannot access. The firmware enforces isolation at the silicon level, so there is no software escape.
Key isolation
Sealed in encrypted memory.
Private keys are generated via CSPRNG inside the enclave, encrypted at rest with a Shamir-split master secret, and exist in plaintext only within hardware-encrypted VM memory during signing. After each operation, key material is explicitly zeroed.
Non-custodial
We can't access your keys. By design.
Sigcore operators, infrastructure providers and the cloud host are all excluded from the trust boundary. The signing primitive is a use operation: the signature is returned, never the key. There is no export path.
Remote attestation
Verify before you trust.
Every enclave generates a cryptographic attestation report signed by the AMD VCEK. The report binds the hardware measurement to the exact software binary running inside. Clients can verify enclave identity before submitting any transaction.
// Attestation report from every signing endpoint,
// signed by the chip's VCEK. Verify before trusting.
report.measurement // sha384 of the enclave image
report.platform // chip identity, TCB version
report.policy // guest policy flags
report.report_data // bound to this session
Enclave-to-enclave
Encrypted service mesh inside the TEE cluster.
Internal services communicate over a custom protocol with X25519 key exchange, Ed25519 identity verification, and AES-256-GCM AEAD encryption with forward secrecy. Every connection is mutually attested: both sides verify each other's enclave measurement before any data is exchanged.
Security invariants
Five guarantees we enforce at every layer.
Private keys exist in plaintext only inside hardware-encrypted VM memory.
AMD SEV-SNP encrypts guest memory with a per-VM AES-256 key managed by the AMD Secure Processor. The hypervisor, host OS and DMA devices are excluded.
At rest, keys are wrapped with AES-256-GCM using a Shamir-split master secret.
The master key is reconstructed only inside the enclave during unseal. Individual shards are held by geographically distributed operators with Ed25519 identity verification.
Key material never transits a network. Signing is a use-only operation.
The vault exposes a gRPC UseSecret(SIGN) primitive. It accepts a payload, returns a signature. There is no ExportSecret path for signing keys. The key stays in the enclave.
After each signing operation, key material is explicitly zeroed from memory.
Using mlock to prevent swapping, MADV_DONTDUMP to exclude from core dumps, and OPENSSL_cleanse for deterministic zeroing that cannot be optimized away by the compiler.
Sigcore operators cannot access keys. The platform is outside the trust boundary.
Remote attestation proves the enclave is running the expected binary. Operators authenticate via challenge-response with Ed25519 but never gain access to secret material.
Request flows
Every request traced. Every boundary enforced.
Step through the four flows that matter: signing, wallet creation, the encrypted channel between enclaves, and passkey login.
- ClientApplication
- SigcoreOrchestrator
- AuthEnclave
- VaultEnclave
- ClienttoSigcorePOST /api/v1/signDPoP proof + JWT
- SigcoretoAuthVerify sessionDPoP + token
- AuthtoSigcoreVerifieduser_id, org_id, claims
The client calls the sign endpoint with a DPoP-bound token, and the Auth enclave checks the token, the proof and the session before returning the verified identity.
Trust model
What we can never do, and what you can check.
Our security posture is documented at the file-and-line level in the TrustCore repositories. This is the summary.
Sigcore can never
- Export a signing key. The vault has no such operation.
- Sign outside your policy. Rules are evaluated before the vault is contacted.
- Read plaintext key material from the host, the hypervisor or the cloud provider.
- Grant operators access to secrets. Operator sessions can govern lifecycle, not read material.
Attestation reports
Each enclave produces a hardware-signed report binding its measurement to the exact binary running inside. Verify it before you trust a signing endpoint.
Signed receipts
Every wallet mutation returns an Ed25519-signed, monotonically counted receipt. Auditors can verify it offline, years later, without trusting our runtime.
Tamper-evident audit log
Vault operations are written to an HMAC-chained audit log synchronously. If the audit write fails, the operation fails.
Responsible disclosure
Found something? Tell us first.
We take every report seriously and reply within two business days. Please give us a reasonable window to fix the issue before publishing, and avoid accessing or modifying data that isn't yours while you test.
[email protected]Ready to see it in your own stack?
Create an account, create a wallet, and verify the enclave attestation yourself.