Every part of CubeSigner reflects a deliberate design choice.

CubeSigner is built to contain risk by design—to limit what can go wrong and minimize the blast radius.

Our Technology

CubeSigner System Architecture

Learn more about our comprehensive security approach.

Authentication Layer

Ensures that every admin and signing request is authorized and authenticated, and lets you detect and revoke compromised accounts early.

Policy Engine

Checks every signing request for compliance with built-in and custom security policies that go beyond allowlists, rate limits, and multi-party approvals.

Virtual HSM

Provides hardware-based signing and cryptographic isolation (from other tenants and Cubist) by coupling a TEE to a FIPS 140-certified HSM.

Principles

CubeSigner Security Properties

CubeSigner is designed to allow the correct people to sign safe messages, without giving them direct access to private keys.

Least Privilege

Complete Mediation

HSM Root of Trust

CubeSigner Technical Design Principles

A few examples, we: Use FIPS 140-certified HSMs as our root of trust—the same hardware that protects the world’s banking infrastructure and the entire internet’s public key infrastructure; we use a simple, mature subset of TPM 2.0 functionality

(instead of the relentlessly broken SGX); we don’t roll our roll our own OS kernel nor rely on experimental libOSes; and we use broadly trusted and formally verified cryptographic libraries.

Among other things, we: Enforce security properties—for example, that a transaction complies with any relevant policies before a key will sign it—with the type system; created a ratcheted

cryptographic protocol that prevents us from seeing secrets and enforces session integrity; and automatically analyze our code and dependencies.

Users can configure their systems so that only the right things can happen. For example, they can: set rules around how a certain group of people can use a certain key (e.g., engineers need approval from finance for high-value transactions);

restrict how funds are spent with custom policy code; require specific 2FA methods (e.g., FIDO) for exceptions; and automatically revoke compromised tokens.

Build on battle-tested components

As academics, we love cutting-edge research; as practitioners, we love simple, well-studied, and broadly-deployed tools.

Favor technical enforcement

It’s worth spending extra effort to enforce security properties by construction.

Assume the user's system is compromised

It's not if, it's when—so we provide multiple layers of defense to help users safeguard their funds even in the worst-case scenarios.

System Components

What we believe shows up in what we've built.

Every part of CubeSigner traces back to a design principle. We’ve spent our careers studying how systems fail—not just in theory, but in the real world, where complexity, pressure, and human error collide. This experience shapes how we think about architecture: where to draw security boundaries, which assumptions to question, and how to make safety the default.

Use only what’s necessary

CubeSigner uses only measurement and attestation from the AWS TPM 2.0 stack. We chose to use TPM 2.0 because it’s simpler—and therefore less error-prone—than Intel SGX or other options, and it’s also mature and well-studied.

Only the enclave can access the keys in the HSM.

TPMs physically isolate the security processor from the main CPU via a narrow, well-defined interface—long the gold standard in secure systems design. Other approaches do everything inside the processor pipeline, exposing a massive attack surface.

Root security guarantees in physical form

Essentially all known key extraction attacks on HSMs require physical access and advanced laboratory equipment. As a result, stealing keys requires breaking into a data center—and data centers take physical security extremely seriously.

Encrypt secrets end-to-end

Imported keys are encrypted directly to the enclave. All keys are backed up as cold-storage ciphertexts, which only the key’s owner can decrypt (e.g., using a YubiKey quorum). Nobody—not even Cubist administrators—can ever see your keys.

Enforce cryptographic isolation

We use cryptography to isolate tenants from each other (and from Cubist), and enforce logical isolation through compile- and run-time checks. As a result, even if there’s a bug in the rest of our system, one customer can never access another’s keys.

Use cryptographic ratchets to secure sessions

We use a novel ratcheting protocol to ensure sessions have forward secrecy (old tokens can’t hijack sessions), post-compromise recovery (stolen tokens can be detected and revoked), and non-custodial design (session secrets stay on user devices, not with Cubist).

Keep the trusted computing base small

The vHSM enclave code is the only code that touches keys, so we minimize its size to reduce opportunities for critical bugs. It’s written in memory-safe Rust and avoids experimental operating systems and complex software update protocols.

Use type- and memory-safe languages

Memory-safety bugs are the leading cause of exploits in OSes, web browsers, and more. We prevent memory-safety bugs by writing all backend code in safe Rust and using Rust's type system to enforce complete mediation (e.g., missing checks cause compile errors).

Reduce and audit dependencies

We keep dependencies minimal, audit them with tools like cargo vet, and use and build modern static analysis tools to check all our code. This defends our system—in particular the backend and cryptographic code—against supply chain attacks.

Audited by Veridise

Veridise is a recognized leader in program analysis, verification, and automated reasoning. Their team conducts thorough and ongoing reviews of CubeSigner’s codebase—including key-handling logic, deployment pipeline, authentication layer, policy engine, and client SDK. Their audits go beyond surface-level checks: Veridise has engaged deeply with the underlying cryptographic protocols and the design decisions behind our implementation.

“Cubist consistently provides high-quality, well-documented code built with a security-first design. Their developers actively collaborated with our auditors and promptly provided fixes. It's a pleasure to review code for Cubist projects.”

Kostas Ferles • Chief Research Officer of Veridise

Security doesn’t stop at the product.

See how we protect data, credentials, and operations.

Go to Information Security