Lombard
  • Unlocking Bitcoin's Potential
    • Introducing Lombard & LBTC
      • Our Value Proposition
      • The State of Bitcoin
      • Lombard's Mission & Vision
  • Lombard's Partners
    • Babylon's Bitcoin Staking
    • Lombard's Security Consortium
  • Bitcoin Staking Partners
  • LBTC: Liquid Bitcoin
    • Introduction to LBTC
    • DeFi Vaults
      • Lombard DeFi Vault
        • LBTC/LBTCv
      • Bitcoin Bera Vault
      • Sentora DeFi Vault
    • Lux & Luminary Program
      • Referral Program
      • Nov. '24 The Golden Bull
      • Dec. '24 Flash Event
    • Staking Yield Distribution
    • Supported Blockchains
    • User Guides
      • Staking BTC & Minting LBTC
      • Unstaking LBTC
      • Lombard DeFi Vault: Depositing & Withdrawing
      • Claiming BABY
      • LBTC Bridging to Sui
  • Technical Documentation
    • Smart Contracts
    • Protocol Fees
    • Protocol Architecture
      • Lombard Ledger (Consortium)
      • CubeSigner: Key Management
      • Bascule Drawbridge
      • LBTC Design
      • Babylon Staking
      • PMM Module
      • Trustless Relayer
    • Oracles
    • Audits & Bug Bounties
    • Sanctions & Risk Monitoring
    • Transaction Tracing
  • Frequently Asked Questions
    • FAQs
      • BABY FAQs
  • Developers
    • Lombard SDK V3
    • SDK FAQ
    • Lombard SDK V2 (deprecated)
  • Quick Links
    • Lombard Website
    • Lombard X (Twitter)
    • Lombard Dune Dashboard
    • Lombard Dune PoR
    • Lombard Discord Server
  • Legals
    • Terms of Service
    • Privacy Policy
    • UK Residents
Powered by GitBook
On this page
  • Hardware-Backed, Non-Custodial Key Management
  • CubeSigner in Lombard's Architecture
  1. Technical Documentation
  2. Protocol Architecture

CubeSigner: Key Management

PreviousLombard Ledger (Consortium)NextBascule Drawbridge

Last updated 4 months ago

Hardware-Backed, Non-Custodial Key Management

CubeSigner is a hardware-backed, non-custodial key management platform built by 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, -sealed —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 that ensure that validators using CubeSigner can't sign slashable messages (e.g., because of ).

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.

Cubist
HSM
Nitro enclaves
anti-slashers for Babylon
operational mistakes or validator client bugs