CubeSigner: Key Management

Hardware-Backed, Non-Custodial Key Management

CubeSigner is a hardware-backed, non-custodial key management platform built by Cubist for programmatically managing cryptographic keys. CubeSigner addresses the security vs availability, tradeoff LSTs have traditionally struggled with by safeguarding keys in secure hardware and restricting how these keys can be used with policies. CubeSigner is designed to:

• Protect against key theft. Keys stay in secure hardware from generation to signing. Since this hardware—in particular, HSM-sealed Nitro enclaves—is designed to prevent key extraction, this means that no one—not even Cubist nor Lombard!—can see user keys, let alone steal them.

• Mitigate breaches, hacks, and insider threats. To sign transactions, Lombard uses CubeSigner signing sessions. These sessions have fine-grained scopes (i.e., they restrict who can sign, which messages, and with which keys), short-lived, and instantly revocable—this lets us ensure each session is least privileged and, even in the case of a breach, useless to an attacker.

• Protect against key misuse. Keys are further protected with custom per-key policies (e.g., "require approval from ⅔ of Consortium members before signing large transactions"). CubeSigner has first-class support for Lombard- and Babylon-specific policies and workflows—even anti-slashers for Babylon that ensure that validators using CubeSigner can't sign slashable messages (e.g., because of operational mistakes or validator client bugs).

CubeSigner in Lombard's Architecture

Lombard uses CubeSigner to generate Bitcoin keys (and their addresses) and restrict how (and when) these keys can be used with policies. This coupling of Bitcoin keys with policies is what Cubist calls hardware-enshrined, off-chain smart contracts. Much like a smart contract on a chain like Ethereum, the hardware-enshrined contract consists of a signing key (which can receive funds) and custom logic—the policy—which controls how those funds are used (beyond what we can enforce with Bitcoin scripts). Lombard implements different kinds of policies, including:

• Access Control: Who can create and use keys, and under what conditions.

• Usage Limits: How many transactions and what types of transactions (including their value, recipient, and kind of transactions) can be signed. For example, user keys can only sign Babylon transactions—not arbitrary Bitcoin transactions. And, even then, the kind of Babylon transactions are restricted. Similar to LST smart contracts, for example, we ensure that deposit transactions use trusted stakers and finality providers, and that the withdrawal address is the Lombard pool address.

• Multi-party Authorization (MPA): MPA policies require multiple users and, typically, multiple factors (e.g., YubiKeys) to sign-off on different operations (e.g., signing transactions or updating policies). This enhances security by, for example, ensuring that no single party can unilaterally authorize a transaction, making the entire process more robust, reliable, and decentralized.

• Timelocks: Keys and policies have timers that prevent even authorized parties from using them. This enhances security by ensuring that a key is timelocked and cannot be used (e.g., for a day) even by authorized (but potentially compromised) parties. We similarly use timelocks to safeguard policy modifications.